Skip to main content
Failures answer the question: what recurring problems keep happening in production? Where Patterns monitor behaviors you already know to watch for, Failures group runtime errors from the execution itself: runs that errored, tool calls that returned errors, and the metadata around them.

​
What is captured

For every run, The Context Company records status, error class, and status message at the run, step, and tool-call level (see what The Context Company captures). Failures are computed from those errors. Each failure includes:
  • Entity type (run or tool_call)
  • Aggregated event count (how often it has occurred in the selected range)
  • First seen and last seen timestamps
  • Status: active, resolved, or ignored
  • Links into the affected runs and traces

​
Using failures

Failures live under the runs / dashboard views and are available programmatically through the REST API. Typical workflow:
1

Rank by frequency or recency

Sort by event count to find the biggest sources of production error, or by last-seen to find what is spiking right now.
2

Filter by entity type

Separate run-level errors (the agent as a whole failed) from tool_call errors (a specific tool returned an error).
3

Open an affected run

Every failure links to the runs that produced it. Open one to see the full trace: the model steps, tool calls, arguments, results, and where the error occurred.
4

Investigate with Insight Search

Use Insight Search to ask “which tools were called just before this error”, “which users are hitting it”, or “did this start with a specific release”.
5

Mark resolved or ignored

Set a failure’s status so it stops surfacing on active dashboards once fixed or intentionally deprioritized.

​
Programmatic access

The REST API exposes failures directly:
Filter by entity_type (run or tool_call) or status (active, resolved, ignored). Fetch a single failure with GET /v1/failures/:failureId. See the API reference. The same data is available from MCP via Insight Search, which lets your coding agent pull the current top failures and their affected runs directly into its context.

​
Failures vs. patterns

Use both. Failures catch runtime problems; patterns catch behavioral ones that the transcript reveals.

​
Limitations

  • Failures aggregate around error classes and messages captured on the run, step, or tool call. Silent failures (the agent claims success while a tool returned an error) surface when the tool call itself errored; if the agent silently swallowed the error before the tool returned an error status, use a pattern or Insight Search to catch it.
  • Grouping is heuristic; use Insight Search to explore boundaries between clusters.

Traces

Open a run to see the exact model step or tool call that failed.

Patterns

Detect behavioral signals that are not raw errors.

Tools and models

Which tools contribute the most to failure rate.

REST API

Query and update failures programmatically.