Lambda errors
Lambda errors, including the ones your handler never sees
Ivy reports every failed Lambda invocation, including the failures an in-process tracer can't see. Init errors like Runtime.ImportModuleError, out-of-memory kills, crashes and timeouts show up as traces with the function's last log lines, throttles are counted per function, and all of it is grouped into error groups that can alert you in Slack.
Why some Lambda failures are invisible
Most tracers live inside your function's process. That works for an exception thrown by your handler, but not when:
| Failure | Why an in-process tracer misses it |
|---|---|
Init errors: Runtime.ImportModuleError, Runtime.HandlerNotFound, Runtime.UserCodeSyntaxError, a throw at module load |
Your code never finished loading, so there is no wrapped handler |
Out of memory (Runtime.OutOfMemory) and crashes (Runtime.ExitError) |
The process dies, and spans in memory die with it |
Timeouts (Sandbox.Timedout) |
The function is stopped before it can report |
| Throttles | The request never reaches the function |
How Ivy catches them
Ivy's Lambda extension runs outside your function's process and subscribes to the Lambda Telemetry API. When the platform reports a failure, the extension:
- completes the invocation's trace (or creates one, if the tracer sent nothing) with the platform's error type:
Runtime.OutOfMemory,Sandbox.Timedout,Runtime.ImportModuleErrorand so on; - attaches the last log lines of the function (at most 50 lines or 8 KB, with your redaction rules applied), so you see
Error: Cannot find module 'left-pad'or V8's heap limit message, not just "failed"; - keeps the spans recorded before a crash or timeout, so you can see how far the invocation got.
The dashboard labels these failures plainly: Init failed, Out of memory, Timed out or Crashed.
Throttles never reach a function, so Ivy reads them from CloudWatch through the same cross-account role: every 5 minutes, an account-level check per region, and per-function counts only when something was throttled. Throttles appear on the function overview, in the function's chart and as a "Throttled" error group. The polling runs in your AWS account (a few cents a month per region in CloudWatch API calls) and can be switched off per account.
No log shipping, no extra cost for healthy invocations
Ivy does not ship your function logs. Log lines are kept in a small buffer inside the extension and only sent when an invocation fails. A healthy invocation adds no extra trace, so it costs nothing extra.
Error groups
Every failure, inside or outside the handler, lands in an error group, fingerprinted by function, error type and normalized message. Each group shows its count, first and last seen, and the traces behind it.
- In the dashboard, under Errors.
- For coding agents, through the MCP tools
list_error_groupsandfind_failing_invocations(see for AI agents). - In Slack and in a weekly email digest, through alerts.
Example: an init error after a deploy
A deploy ships a bundle that is missing a dependency. Every cold start fails before your handler runs, so callers get errors and an in-process tracer reports nothing. In Ivy you see an error group like:
checkout-createOrder · Init failed · Runtime.ImportModuleError
Error: Cannot find module 'left-pad'
12 occurrences · first seen 10:04 · last seen 10:09with a trace per failed attempt and the log lines the runtime printed.