What is serverless observability?

Logs, metrics, traces, and business outcomes

Logs explain discrete events with context, metrics show behavior over time, and traces connect work across service boundaries. None is sufficient alone: a healthy function metric does not prove that an order, payment, or notification completed.

Start with customer and business outcomes, then connect them to service and operational signals. This hierarchy helps alarms express impact while dashboards and traces provide evidence for investigation.

Correlate one operation across services

Generate or preserve a correlation identifier at the entry point and include it in structured logs, messages, events, and workflow state where safe. Also record stable domain identifiers that let an operator find the affected business operation.

Correlation must survive asynchronous boundaries. A trace may end before a queued consumer runs, so logs and event metadata should preserve enough context to rebuild the path without copying secrets or personal data everywhere.

Alarm on impact and leading indicators

Alarm when customers cannot complete important operations and when leading indicators show that impact is approaching. Queue age, dead-letter activity, throttling, workflow timeouts, authorization denials, and dependency latency often matter more than raw invocation counts.

Every page should have an owner, a severity, a useful threshold, and a runbook. Review noisy or unactionable alarms rather than training operators to ignore them.

Design for investigation and recovery

Dashboards should let an operator move from customer impact to the affected path, deployment, dependency, account, region, and individual operation. Retention and access policies must support incident review without exposing sensitive data unnecessarily.

Observability is complete only when the team can act. Link signals to rollback, replay, redrive, throttling, isolation, or manual completion procedures and test those procedures before the incident requires them.