Serverless monitoring for Lambda, Cloud Run and Azure Functions

What is serverless monitoring?

Serverless monitoring is the observation of applications built on managed compute services such as AWS Lambda, Google Cloud Run and Azure Functions, where the cloud provider runs and scales the infrastructure for you. Instead of hosts and processes, you monitor invocations, containers that start on demand and the events that trigger them: HTTP requests, queue messages, file uploads, schedules and database changes.

Serverless removes a lot of operational work, but not the need for visibility. You still own the code, its dependencies, its configuration and the user experience. And because there is no server to log into, telemetry is the only way to understand what happened during a slow or failed invocation.

Why serverless monitoring matters

Serverless architectures are highly distributed and event-driven. A single user action can trigger an API gateway, several functions, a queue, a stream and a database write. When something fails, the error often surfaces far away from its cause, for example as a growing dead-letter queue rather than a visible exception. Without distributed tracing, these asynchronous chains are almost impossible to follow.

Serverless also introduces specific failure modes. Cold starts add latency when new instances are initialized. Concurrency limits cause throttling under load. Timeouts and memory settings affect both performance and cost, because billing depends on duration and allocated memory. A small regression in a frequently called function can noticeably increase your cloud bill. Monitoring helps you find the right balance between latency, reliability and cost.

Key serverless metrics

• Invocations and concurrency: request volume and how many instances run in parallel, compared with configured limits.
• Errors and throttles: failed invocations, timeouts and requests rejected because of concurrency limits.
• Duration: p50, p95 and p99 execution time, which drives both latency and cost.
• Cold starts: how often new instances are initialized and how long initialization takes.
• Memory usage: peak memory compared with the allocated size, to rightsize functions.
• Trigger health: queue age, iterator age for streams, dead-letter queue depth and retry counts.
• Downstream latency: time spent in databases, APIs and other services called by the function.

How Obseria handles serverless monitoring

Obseria connects to AWS, Azure and Google Cloud and collects function metrics and logs agentless, as part of its coverage of 300+ cloud services. For traces, you instrument functions with OpenTelemetry, using the SDKs or layers you may already have, and send data over OTLP. Trace context is propagated through HTTP calls, queues and event triggers, so Obseria can stitch asynchronous flows into one end-to-end view.

Obseria TopoGraph shows how functions connect to gateways, queues, databases and containerized services. When error rates rise, Obseria Intelligence checks the related signals, such as a new function version, throttling on a downstream database or a growing queue backlog, and presents a chain of evidence for the most likely root cause. Tail-based sampling keeps all slow and failed invocations while reducing volume for routine traffic.

You can analyze cold starts directly with OQL:

fetch spans
| filter faas.coldstart == true
| summarize count(), p95(duration), by:{faas.name, cloud.region}

Because Obseria prices per signal and not per host or function, adding new functions does not change your license; you pay for the telemetry you ingest and keep.

Serverless monitoring best practices

1. Propagate trace context everywhere. Make sure context survives queues and event triggers, or traces will break at every asynchronous hop.
2. Measure cold starts separately. Track them as their own signal so they do not hide inside average latency.
3. Rightsize memory with data. More memory often means more CPU and shorter duration; test the trade-off against cost.
4. Watch dead-letter queues. They are where silent failures accumulate.
5. Use structured logs. JSON logs with request IDs make it easy to correlate logs with traces.
6. Tag by version. Compare function versions to catch regressions right after deployment.