// guide
What is worth alerting on for a Lambda, what is only worth collecting, and how to avoid maintaining alarms per function per metric.
10 min · you run Lambdas · updated 28 July 2026
AWS is not connectable right now. The AWS integration was withdrawn on 14 August 2026 — it is built and unchanged, but it cannot be connected while its setup flow is reworked, and existing connections have stopped collecting. The reasoning below still holds; the Beaam-specific steps do not work today. See the AWS integration page for current status.
CloudWatch already has the data. Errors, throttles, duration, concurrency, cold starts — all of it, per function, retained and queryable. The problem is never collection.
The problem is that turning it into alerting means creating alarms per function per metric, with thresholds you choose in advance and maintain forever. Ten functions and four metrics is forty alarms. Deploy a new function and you have either remembered to add four more, or you have a blind spot you will not discover until it matters.
Of everything a Lambda emits, a short list is genuinely attention-worthy:
Errors. Almost always. A Lambda that throws is a request that failed, and unlike a web server there is rarely a graceful degradation path. Beaam treats any error in the window as broken — deliberately aggressive, because “some errors are normal” is how you end up ignoring the metric entirely.
Throttles. You have hit a concurrency limit, so invocations are being rejected. Treated as degraded: real, but usually not the same emergency as outright failure.
Step Functions failures. If you orchestrate, a failed execution means a workflow stopped partway. Broken — partial completion is often worse than not starting.
Duration, concurrency, cold starts, invocation counts. All useful for understanding why something broke, none worth a 3am message on their own. A Lambda getting slower is a thing to look at on Tuesday.
This split — curate what alerts, be generous with what you collect — is the whole design. Alert on everything you collect and you have alarm fatigue; alert on nothing and you have a dashboard.
The reason alarm sprawl happens is that alarms are attached to named resources. Add a resource, and you must remember the alarms.
Connect an AWS account to Beaam and it discovers what is there — EC2, Lambda, Step Functions, RDS, DynamoDB, load balancers and SQS, across every enabled region — and applies the defaults above. A function deployed next month is discovered rather than forgotten.
Access is a one-click CloudFormation role with an external ID. No IAM user, no long-lived access keys, and read-only: Beaam has no code path that mutates your infrastructure.
The failure people miss most often is not the function — it is the queue in front of it. A consumer that has silently stopped produces no errors at all, because it is not running. Every metric on the function looks perfect.
The signal is backlog age. Beaam alerts when the oldest message in an SQS queue reaches five minutes, which is the practical definition of a stuck consumer. This is the single highest-value AWS alert for most small stacks, and the one hand-built alarm sets usually lack.