Observability

Observability is how a Norscode service explains itself while it is running. Good observability makes it possible to answer practical questions quickly: is the service healthy, is it ready for traffic, is it slower than normal, which requests are failing and what changed recently?

Health and readiness

Separate basic liveness from readiness when possible. A process can be alive while still not being ready for traffic because a dependency is missing, a migration is still running or a warm-up step has not completed.

returner web.http_json_respons("{\"ok\":true,\"service\":\"norscode\",\"ready\":true}")

Logs and correlation

Logs become far more useful when they share stable fields such as event, level, route and request_id. Correlation IDs make it possible to follow one request across validation, domain logic, integrations and response formatting.

Metrics and alerts

Start with a few signals that actually matter: response time per endpoint, error rate, active requests and retry or timeout patterns. Then define alerts that map to action. Warning-level alerts should suggest investigation. Critical alerts should mean someone needs to react immediately.

Observability works best when it is connected to logging, deploy and reliability rather than treated as a separate reporting layer.