Diagnose an incident
get_incident_diagnosisDiagnose a monitor incident by reading what changed around the failure—state, reason, per-region baseline and findings—before fetching raw checks or incident details.
Instructions
Read what changed around a monitor incident, computed from the checks Fettle already holds. Start here for a DOWN monitor's open incident (its id from list_incidents with monitor_id and status "open") or a pasted alert, before get_incident or list_check_results. Returns incident_id, state, reason, summary (one line) and diagnosis (window, per-region baseline and state, layer, platform and findings, each with kind, rank, regions and facts) and agent (layer, window with last_good_at, first_bad_at and onset_at, repro: a shell command that repeats the probe from the current config, plus check_target with the type, target and non-secret config to send to check_target; and next_calls: up to three tool calls with ready arguments, to follow in order). The command hides header values (), the body (read from body.txt), the target's userinfo, token-like path segments and the values of query parameters named like key, token, secret, sig, password, pass, auth, credential or session (), and drops the fragment; check_target leaves the userinfo and those query values out, so for such a target take the full one from get_monitor. check_target and check_now need the write scope. agent is null when the monitor was deleted; repro is null when no command fits (a TCP monitor without a port). A deploy recorded with record_deploy for this monitor up to 2 h before the onset is the finding DEPLOY_BEFORE_ONSET (minutes_before_onset); on RECOVERY, one between the outage start and the first green check is DEPLOY_DURING_OUTAGE; its ref and compare_url are in diagnosis.context.suspect_deploy and next_calls then offers verify_deploy. A deploy close in time is not proof it caused the failure. These are observations, not proven causes: say what was seen, not why. state READY has summary, diagnosis and agent (see above); PENDING means it is still being computed (ask again in a minute); a READY RECOVERY answer with refinement_pending true has no verdict yet on slower responses (RECOVERED_SLOWER needs the 10 minutes after the first green check and lands about 12 minutes after the resolve; ask again then, and a minute later while refinement_pending is still true); UNAVAILABLE has a reason: NOT_APPLICABLE (a heartbeat has no probes), NOT_COMPUTED (none will come) or NOT_RESOLVED (RECOVERY asked of an open incident). Ignore finding kinds and fields you do not know. HTTP detail depends on diagnosis.detail_level: BASIC has no redirect, final-URL, TLS or header-change findings; the edge-block and PLATFORM_ERROR findings need only the first failed check's details. platform and PLATFORM_ERROR are hints from response headers, not causes. For raw checks use list_check_results, for the incident row and alerts get_incident.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| phase | No | OPEN (default): what changed when it failed. RECOVERY: what changed when it came back (how each region recovered, slower responses, a new DNS answer or certificate, a deploy during the outage); PENDING for a few minutes after the resolve. Anything else is a 422. | |
| incident_id | Yes | The incident's uuid from list_incidents. An id that is not an incident of this organization is a 404. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| agent | No | ||
| state | Yes | Known values: READY, PENDING, UNAVAILABLE. | |
| reason | No | ||
| summary | No | ||
| diagnosis | No | ||
| incident_id | Yes | ||
| refinement_pending | No |