crashes

What this detector catches

Any exception that escapes the @wrap boundary produces a crashed execution status and a failure-group entry under failure_class = crashes. The signature is a 16-character SHA-256 hash derived from the exception class name plus the top of the traceback. Two executions that fail with the same exception type at the same call site get the same signature regardless of differences in the arguments that triggered the failure.

The raw exception message is not stored — only its hash. Customer PII in exception text never reaches the backend.

Example failures it groups

• A ValueError raised inside the agent function because json.loads()couldn't parse the model's output.
• A RateLimitErrorfrom the LLM provider that the agent didn't catch.
• MemoryError on an execution that accumulated too much context.
• Unbounded recursion / stack overflow on a tool that calls back into the agent.
• Any exception from a tool call that the agent didn't catch (these escape as crashes; tools that DO get caught but fail are handled by the tool_failures detector instead).

What to do when it fires

Open the failure-group detail page in the dashboard. The Playbook panel walks the diagnostic framework: compare crash signatures across affected executions (matching signatures mean structural / reproducible; varying signatures mean data-dependent), inspect the last event before the crash in the timeline, and compare inputs across 2-3 affected executions to find a minimal repro. Common remediation patterns covered in the playbook: typed validators on parsed model output, startup health checks for credentials, bounded list accumulators for OOM, depth-counter caps for unbounded recursion.

When NOT to investigate

• Known-harmless exceptions your agent raises deliberately as a control signal (custom rate-limit markers, expected retry exceptions, domain-specific business-logic flags). Allowlist the exception type via Allowlist — the detector skips grouping and skips webhook delivery for matching crashes.
• Cross-tenant provider outages. A spike of crashes correlated with one model provider is usually a provider incident, not a code bug. Check the provider_incident failure group for the same time window before debugging your agent.
• First-fire after a fresh deploy. The first crash of a new signature is almost always the diff between the last green deploy and the current one. Roll back, then investigate.

Tunable thresholds + allowlist

The crashes detector has no per-project tunable thresholds — every crash fires the detector. Use the Allowlist primitive to suppress known-harmless exception types: add an entry whose allowlist_key matches the exception type (e.g. ValueError) and matching crashes skip grouping + skip webhook delivery while the entry's lifetime match-count increments so you can see how often the suppression is doing work.

Related docs

• tool_failures — for tool exceptions the agent caught (silent degradation pattern); crashes is for exceptions the agent did NOT catch.
• provider_incident — check this first when crashes spike correlated with one LLM provider.
• Allowlist — suppress known-harmless exception types.