"Serverless" is a lovely promise: write a function, deploy it, and the platform runs and scales it for you — no servers to patch or watch. But "no servers to monitor" doesn't mean "nothing to monitor." It means the things to monitor change.
Functions have their own failure modes — cold starts, timeouts, throttling — and the usual server metrics (CPU, disk) don't apply. Here's what to watch instead.
What's different about serverless
| Traditional server | Serverless function |
|---|---|
| Long-running process | Spun up per request, then gone |
| Watch CPU/memory/disk | Watch duration, invocations, errors |
| You manage capacity | The platform scales it |
| Predictable warm state | Cold starts when scaling up |
Because functions are ephemeral, you can't "log into the box." You monitor the invocations and what the platform reports.
The signals to watch
Cold starts
When a function hasn't run recently (or is scaling up), the platform must initialise a fresh instance — a cold start — adding latency to that invocation. Too many cold starts mean a sluggish, inconsistent experience. Watch how often they happen and how much they add to latency.
Duration (and timeouts)
Functions have a maximum duration; exceed it and the invocation is killed. Watch execution time — especially the p95/p99 — and how close it runs to the timeout limit. A function creeping toward its limit is an outage waiting to happen.
Errors and throttles
| Signal | Meaning |
|---|---|
| Error rate | Functions failing (bugs, bad input, dependency failures) |
| Throttles | The platform rejecting invocations past a concurrency limit |
| Invocation count | Demand — and a proxy for cost |
Throttling is the sneaky one: hit your concurrency limit and the platform starts rejecting requests, even though nothing is "broken." Watch for it.
Cost
Serverless bills per invocation and duration, so a runaway loop or a traffic spike shows up directly on the bill. Monitoring invocation volume doubles as cost control.
The blind spots to cover
Serverless monitoring has two gaps worth closing:
- The platform's own metrics lag and aggregate. They're useful but not always real-time per request. Pair them with tracing for request-level insight.
- "Is the endpoint actually working for users?" Platform metrics can look fine while an API Gateway misconfig, a permissions error, or a cold-start storm degrades the real experience. So keep external uptime/API checks on your function-backed endpoints — synthetic checks from multiple locations are the ground truth.
The bottom line
| Watch | Why |
|---|---|
| Cold starts | Latency spikes when scaling up. |
| Duration | Approaching the timeout = failures coming. |
| Errors & throttles | Bugs, and rejected invocations at the concurrency limit. |
| Cost / invocations | Runaway usage shows up on the bill. |
| External checks | Confirm the endpoint works for real users. |
Serverless removes the servers, not the need to watch. Track cold starts, duration, errors and throttles from the platform — then anchor it all with external checks on the endpoints your users actually hit.
Related: API monitoring, latency percentiles, observability vs monitoring.