Honua
// ease of operations

Keep GIS healthy.
Keep your team in control.

Honua brings day-two GIS work into the platform routines your team already uses. Check health and readiness, follow requests through OpenTelemetry, review configuration in Git, and release through your existing deployment controls. Operators get a clear view of the system without giving up the approval boundaries that protect production.

Runtime · health
healthup
readinessready
trafficenabled
Configuration · reviewedCURRENT
settingsin Git
secretsreferenced
releasepipeline
Signals · OpenTelemetryEXPORTING
p50p95p99errorsrequests // export to your observability stack
// know what is happening

See the signal.
Find the affected request.

Routine checks should fit the same dashboards, alerts, and on-call habits as the rest of your services.

01 · Health and readiness Give your orchestrator a direct view of runtime state.

Use health and readiness endpoints for platform probes and rollout gates. Readiness keeps traffic away until an instance can serve it, while health gives operators a simple signal for the running process.

02 · Request telemetry Follow GIS work through the observability stack you already watch.

OpenTelemetry exports request traces, metrics, and structured logs to the backend you configure. Investigate latency and errors with request context instead of stitching together a separate GIS-only monitoring workflow.

03 · Clear configuration Keep runtime choices visible and repeatable.

Store settings with the deployment configuration and keep secrets out of it. Honua resolves configured secret references from your cloud secret manager at startup, so credential handling stays inside your platform boundary.

// telemetry reference

What telemetry actually ships.

Mined directly from the public honua-server source so you can wire probes, scrapes, and dashboards before the first deploy: the endpoint paths, the metric names, the structured-log shape, and the span vocabulary.

Endpoints

Health, readiness, and metrics endpoint paths
PathWhat it servesAccess
GET /healthz/liveLiveness probe — returns 200 Healthy while the process runs.Unauthenticated (probe-safe)
GET /healthz/readyReadiness probe — runs the readiness check service (backing stores and dependencies) before an instance takes traffic.Unauthenticated (probe-safe)
GET /healthz/metricsJSON performance snapshot: readiness detail, database performance metrics, cache refresh state.Admin authorization
GET /metricsPrometheus text exposition of the OpenTelemetry meters. Path is configurable via Observability:Prometheus:Path.Admin authorization
OTLP pushTraces, metrics, and logs export over OTLP when OTEL_EXPORTER_OTLP_ENDPOINT (or the tracing options) is set.Operator-configured

Key metrics

117 metric instruments are registered in the source at the mined commit. The rows below are the ones an operator dashboards first; each registers on the exported Honua meter, so they appear in both the Prometheus scrape and the OTLP stream.

Key metric instrument names and meanings
MetricInstrumentWhat it tells you
honua_serving_request_duration_mshistogramServing-plane latency tagged protocol / operation / status_class — p95 by GeoServices, OGC, WFS, or OData family instead of by route.
honua_request_error_totalcounterProtocol error envelopes across every surface; the in_band tag marks errors delivered inside 2xx bodies that load-balancer 5xx metrics never see.
honua_geoservices_error_totalcounterGeoServices/ArcGIS REST {"error": …} envelopes by service_type / operation / error_code.
honua_http_request_duration_mshistogramHTTP request latency (with honua_http_request_total and honua_http_active_requests).
honua_database_query_duration_mshistogramDatabase query latency (family includes honua_db_pool_utilization_ratio and connection acquisition/timeout counters).
honua_cache_hits_total / honua_cache_misses_totalcountersCache effectiveness, with honua_cache_hit_ratio and eviction counts alongside.
honua_coordinate_transform_totalcounterReprojection volume (with honua_coordinate_transform_duration_ms for cost).
honua.tile.jobs.queue_depthup-down counterTile export job backlog (family: honua.tile.jobs.duration_ms, tiles processed, archive sizes).
honua.streaming.slow_consumer_drops_totalcounterFeature-stream events dropped on slow consumers (family: sessions opened/closed/rejected, replay deliveries).
honua.alerts.deliveries_failed_totalcounterAlert deliveries that failed (family: succeeded, suppressed, dead-lettered, plus honua.alerts.delivery_latency).
honua.outbox.dispatched_totalcounterEvent-outbox dispatches (family: failed, dead-lettered, recovered claims).
honua.spec.apply_duration_mshistogramDeclarative spec apply duration (family: applies started/completed, nodes processed).

Structured logs

Production logs are Serilog compact JSON (CLEF) on stdout, enriched with OpenTelemetry trace and span IDs. Every request logs one completion event; the field shape below is from source, the values are illustrative. Query strings are deliberately never logged, so credentials or tokens in URLs cannot reach log sinks, and health-probe requests log at Verbose.

stdout · production · one request completion event (CLEF)
{"@t":"2026-08-09T17:21:08.301Z",
"@mt":"HTTP {RequestMethod} {RequestPath} responded {StatusCode} in {Elapsed:0.0000} ms",
"RequestMethod":"GET","RequestPath":"/rest/services/parcels/FeatureServer/0/query",
"StatusCode":200,"Elapsed":41.7305,
"HonuaProtocol":"FeatureServer","HonuaOperation":"query",
"ServiceId":"parcels","LayerId":"0",
"TraceId":"4bf92f3577b34da6a3ce929d0e0e4736","SpanId":"00f067aa0ba902b7",
"MachineName":"honua-7d9c","ThreadId":18,"EnvironmentName":"Production",
"Application":"Honua","Version":"1.0.0"}

Spans

Tracing registers the Honua ActivitySource plus named subsystem sources (routing, geocoding, import jobs, provider feature stores). Span names are lowercase dot-paths of component.operationhonua.feature.query, honua.db.query, honua.tile.generate, routing.solveRoute, zarr.raster-slice.read — carrying attributes such as honua.protocol, honua.service.id, honua.layer.id, and honua.operation.

// Extracted from public source at commit 1585115 (honua-server trunk, 2026-08-09) — not a versioned release contract; names can move between releases. Primary sources: src/Honua.ServiceDefaults/HonuaTelemetry.cs, src/Honua.ServiceDefaults/Extensions.cs, src/Honua.Server/Features/HealthCheck/HealthEndpoints.cs, src/Honua.Server/Program.cs.

// make changes safe

Move quickly without hiding the decision.

Configuration, upgrades, and recovery work stay explicit. Your team can inspect the intended state, decide who approves it, and choose when it reaches production.

01 · Review in Git Make configuration changes understandable before they run.

Propose the change in version control, inspect the diff, run your checks, and merge through the ownership rules you already use. The change record keeps the reason and review beside the configuration.

02 · Control upgrades Pin the server image and configuration you intend to release.

Test that combination against representative data and traffic, then promote it with your deployment tooling. Treat database, schema, and data migrations as separate release boundaries that need their own review.

03 · Define rollback Know what can move backward before production changes.

Keep the prior image and configuration available for reversible releases. When a change also transforms schemas or data, pair deployment rollback with a tested restore or forward-fix plan instead of assuming every change can be undone.

Pilot access The Honua operator can prepare plans and pull requests for one environment. People retain approval and release control. Fleet promotion and verified rollout across environments are not available yet. See AI-assisted operations for the focused workflow.
// calm day-two operations

Make the routine work visible.
Keep people at the controls.