Timeline of an incident
incident_timelineThe incident’s public status updates and internal team notes (each note with who wrote it and via, the channel: app, api, mcp for an AI assistant, email, slack or telegram), each time it was acknowledged or the acknowledgement taken back (acknowledgements, with who, when and via), plus the alert channels that were notified, deploys shortly before it began, who PagerDuty is paging, notes from PagerDuty and tickets opened for it. An update with posted_automatically was posted by InfraNest from the incident’s draft, because your workspace lets drafts post without asking. status_draft is the status page update this incident would post, ready for you to send with POST …/updates: kind is opened (the outage is real by your rule in GET …/incident-status-rule and nothing has been posted about it yet) or resolved (it recovered after an update was posted, and nobody has said it is over). It carries the status and message to send, the status pages and components it names, how long it has been down (down_minutes), from how many locations it was seen down (locations_down of locations_checked, null when the monitor has no per-location results) and whether your workspace posts it without asking (auto_post). targets lists where it is posted: once per status page it names, on an incident that page shows (incident_id, the page_ids showing it, and notify_page_ids when only some of those pages’ subscribers are told, because another update already reached the rest). For an outage across several monitors on different status pages, that is more than this incident. It is null for a blip, for an incident on no status page, for planned work and for a monitor behind a provider that reports its own outage. report is the incident’s postmortem in a docs tool such as Notion (provider, its title as label, url and created_at), or null; while it is null, report_writer names the connection that would write one (connection_id, provider), or is null when nothing that writes postmortems is connected. Each of tickets carries the link’s id (what unlinking it names), its own title when InfraNest saw it filed or linked, who it is assigned to (assignee, as the tracker’s webhook last said), how it came (origin: filed, linked or automation) and when InfraNest last heard of it (synced_at). review summarises the team’s review, or is null: how many of its four parts are written (parts_filled of parts_total), its follow-ups and how many are done, state (draft or done), owner, the keys of follow-up tickets still open, and copies, every place it is published to or linked from. Every update, team note and acknowledgement of one incident, plus the deploys near its start. To find out why it happened, follow a deploy with deploy_changes and check dns_zone_changes and search_audit_log for that time.
Tool call template
Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {
"incident_id": "<incident_id>"
},
"name": "incident_timeline"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| incident_id | Yes | The incident id, from list_incidents or status_overview. | |
| organization_id | No | The organization to read. Leave it out when the token reaches only one. |