Technology
Monitoring and observability for public-facing services
How agencies know their online services are working, and what to measure.
Online services fail quietly. Residents who cannot complete a task give up rather than report it. Monitoring is how an agency learns about problems first.
What to collect
Logs. Structured records of what happened, centralized and searchable, with retention aligned to policy.
Metrics. Request volume, error rate, response time, and resource saturation, over time.
Traces. The path of individual requests across components, for diagnosing slow or failing transactions that span systems.
Synthetic checks. Scripted transactions run from outside the agency network at intervals, testing the real public experience.
What to alert on
Symptoms that residents experience: elevated errors, slow responses, failed synthetic transactions, expired certificates. Alerting on every internal metric produces noise that is ignored.
Who responds
An alert needs a recipient with the ability to act. For agencies without around-the-clock staff, a support agreement with a vendor, with defined escalation, fills the gap. Define this before the first outage.
Dashboards
One view per service showing traffic, errors, latency, and saturation. Status should be evident at a glance.
Public status
A status page for resident-facing services, updated during incidents, reduces calls and builds trust.
Retention and privacy
Logs may contain personal data. Apply retention rules and access controls, and avoid logging more than needed.
Building it in
Monitoring added after launch is always incomplete. Include logging, metrics, synthetic checks, and dashboards in the definition of done for every service, and in acceptance criteria for vendor-delivered systems.