list_open_incidents
Get every open incident from an agent's monitors, newest first, to discover what broke during downtime and use failure context (cause, exit code, repeat count) to decide retry or escalate.
Instructions
Read this agent's failure inbox: every incident currently OPEN on the monitors it owns, newest first. Call it at the START of a run, before doing the work — this is how an agent finds out what broke while it was not running, with no webhook, chat integration or mailbox to wire up. What makes the payload worth reading is NOT 'your check failed' — the run that failed already knows that. It is the context that no single failure body can contain:
failure_signature.occurrences — how many times THIS EXACT failure has been seen on this monitor (with first_seen/last_seen, and a fingerprint you can use to correlate incidents yourself). First occurrence or fortieth repeat is the fact that decides retry versus escalate, and no amount of reasoning over one failure body can recover it.
failed_step — the last step the run reported before it stopped. For a 'stalled' incident this is the entire diagnosis: the run is still alive and has not moved past this step.
exit_code — the status the run exited with. 137 (SIGKILL, usually the OOM killer) and 1 are both the word 'fail' and are completely different problems.
duration_vs_normal — a COMPARISON, not a measurement: '8.2x the typical run (41m vs 5m), from 30 archived days'. run_ms, typical_ms, ratio and days_sampled are carried too, so you can apply your own threshold and tell a 30-day norm from a 2-day one.
cause — 'silence' and 'fail' demand opposite responses. 'fail' means the job ran and reported an error; 'silence' means it never reported at all, which usually implicates the scheduler or the host rather than the job.
body_excerpt (the error text the failing run actually printed), run_id (line the incident up against your own logs), and ci.run_url (where the full log is, when the failure came from a CI provider). ABSENCE MEANS NO EVIDENCE — NEVER GOOD NEWS. Every enrichment degrades to ABSENT rather than erroring, so a missing field is the ordinary case, not an error. A missing duration_vs_normal means the run's duration or the monitor's baseline is unknown; it does NOT mean the run took a normal amount of time. A missing exit_code means no numeric code was reported (the ping used a word form such as /fail, or a detector opened the incident with no ping at all); it does NOT mean the job exited cleanly — and exit_code 0 is a real value this field does report, on a run that claimed success and then failed its declared expectations. A missing failure_signature or failed_step reads the same way: not known, never 'none'. Then WRITE BACK what you found with add_incident_note, passing the incident_id from the entry you acted on. Reading the inbox and saying nothing leaves the human exactly where they were.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max incidents to return (default 50, max 200). Newest first, so a small limit drops the oldest open incidents, not the newest. | |
| agent_id | Yes | Agent UUID (from register_agent or list_agents). The inbox covers every monitor this agent owns. |