Devops Get Incidents
devops_get_incidentsRead-onlyIdempotent
Fetch incident history and scheduled maintenance windows for a vendor. Returns full incident timeline — each investigator update, affected components, and resolution. Filter by status to focus on active incidents (use before deploy), resolved history (for postmortem), or maintenance windows: upcoming and in-progress ones, plus completed ones on Atlassian Statuspage, Firehydrant, and Datadog vendors (Status.io vendors list upcoming and in-progress only). Narrow further with match (terms in the title or affected component names, plus location names and IDs on Google Cloud and AWS) and since/until (a start-date range) — all applied before paging, so totals count only what they keep. Page through long histories with limit + offset — a truncated result discloses the total and returns the value to page with in nextOffset. Each response is held to 64,000 bytes per surface: a page can stop short of limit at that budget (the paging fields and notice say so), and an incident too large on its own keeps only its newest updates, with updates_omitted counting the rest — full_updates: true returns them all. Some vendor feeds cap their own history: when upstreamCeiling is present the vendor API returned everything it will serve, and older incidents are not reachable at a higher offset; the notice says whether since reaches them. On Atlassian Statuspage vendors, since (a date) also reads the status page's quarterly history archive back to that date, or 24 months back at most, where the page publishes one — not on a vendor that covers only part of a shared page, such as "sendgrid"; those records are marked source: "history" and carry the title, impact, start and end times, and final update message only. An empty result, or a history read that stopped short of since, explains itself in notice.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum incidents to return per call, at least 1. A value over 50 is served as 50, and the notice says so. Page through longer history with offset rather than raising this. | |
| match | No | Terms to look for, separated by spaces, in each incident's title, its affected component names, and, on Google Cloud and AWS, its affected location names and IDs ("us-central1", "me-south-1", "bahrain"), ignoring case. An incident is kept when every term appears in its title, one of its component names, or one of its location names or IDs, each term on its own. A one-word term matches all or part of a word. A term whose words are joined by punctuation ("eu-central-1", "git-operations", "git/operations") matches only where those words appear together, in that order, within one of those texts, anywhere in it: "eu-central-1" finds eu-central-1 but not me-central-1, and "eu-west" finds every eu-west region. History-archive records, and vendors that publish no components, match on title alone. Applied before limit/offset, so totals and paging count only the matches. Leave blank to keep every incident. | |
| since | No | Earliest start date to include, as YYYY-MM-DD (UTC). Accepted with filter "all" or "resolved". A record's start is its scheduled_for, else the earlier of its started_at and created_at; records that started before since are left out, and limit/offset page the rest. On Atlassian Statuspage vendors it also reads the status page's quarterly history archive back to this date, reaching incidents older than the 50 the status API serves — except on a vendor that covers only part of a shared status page (such as "sendgrid" on Twilio's page), whose archive records carry no components to narrow by. The archive is read back 24 months at most: for an earlier date, older records come only from what the status API still returns (such as completed maintenance windows), and the notice gives the date the archive was read back to. On a vendor with no archive this tool reads, since filters only what its status feed returns. Where that feed is a recent window, a since earlier than the oldest record it returned gets that record's start date in the notice. A feed that carries its page's whole history (such as "redis-cloud" or "datadog") holds nothing older, so it gets that date only on an empty result whose until is earlier than it. Omit to read only the status API. | |
| until | No | Latest start date to include, as YYYY-MM-DD (UTC) — the whole day, so until equal to since returns that one day. Accepted with filter "all" or "resolved", and on or after since. A record's start is its scheduled_for, else the earlier of its started_at and created_at; records that started after until are left out before limit/offset page the rest. It reads no history archive on its own: set since as well to reach incidents older than the status API returns, through an archive read back 24 months at most. On a vendor with no archive this tool reads, until alone filters what its status feed returns. Where that feed is a recent window, the notice then gives the start date of the oldest record it returned. A feed that carries its page's whole history (such as "redis-cloud" or "datadog") gets that date only on an empty result whose until is earlier than it. | |
| filter | No | all: incidents plus scheduled maintenances. active: only incidents with status investigating/identified/monitoring. resolved: only fully resolved incidents. scheduled: only maintenance windows — upcoming and in-progress ones, plus completed ones on Atlassian Statuspage, Firehydrant ("redis-cloud"), and Datadog ("datadog", "datadog-eu1") vendors; Status.io vendors ("gitlab", "neon") list upcoming and in-progress windows only. Not every vendor backend serves every filter — "aws" lists a resolved event only until it drops off its feed, "azure" lists open items only (never resolved), and "aws", "azure", "azure-devops", "gcp", and "slack" publish no maintenance windows. An empty result names which case applied. | all |
| offset | No | Number of matching incidents to skip before applying limit, for paging through history. 0 (default) returns the most recent page; a truncated result returns the value to use next in the nextOffset field. Raising offset past the number of matches returns an empty list and says so. | |
| vendor | Yes | Vendor slug (e.g., "github", "aws") or raw Atlassian Statuspage base URL. Use devops_list_vendors to find slugs. | |
| full_updates | No | Return every update of an incident that is too large for the response size budget on its own, instead of only its newest updates. Default false. Pair it with limit: 1 and the offset the notice names; the response can then run past the budget. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cap | No | The limit that was applied: the requested limit, or 50 when a larger one was requested. Present only when truncated. | |
| name | No | Display name of the vendor. | |
| error | No | Present when the call failed. Absent on success. | |
| shown | No | Number of incidents on this page: the limit, or fewer when the page stopped at the response size budget. Present only when truncated. | |
| notice | No | Plain-language explanation of this result — a limit over 50 that was served as 50 (with the requested and effective values), a since older than the 24-month history-archive floor (with the date the archive was read back to), a since earlier than the oldest record a vendor feed that is a recent window with no history archive behind it returned, or an until without since on such a feed (with that record's start date), how to page onward, that the page stopped at the response size budget or left out an oversized incident's oldest updates (and the call that returns them all), why it came back empty (the vendor currently publishes nothing at all, a capped feed of a shared status page that returned nothing touching the vendor's components, a filter the backend cannot satisfy, an offset past the end, a since/until range or match terms that left everything out — naming the archive floor when the range reaches back past it, and where a feed that carries its page's whole history starts when the range ends before that), that the vendor feed capped the history (and whether since reaches past that cap), or how far the history archive was read when it stopped short of since or its floor. On a vendor that reads an umbrella status page with no components, such as "atlassian", its last sentence names the product slugs to check instead. Absent when the result needs no explanation. | |
| vendor | No | Vendor slug or URL as provided. | |
| incidents | No | Matching incidents. | |
| truncated | No | True when more incidents matched than this page returned — because of limit, or because the page stopped at the response size budget. Absent when this page reached the end of the matches. | |
| nextOffset | No | The offset to pass on the next call to continue from where this page stopped, already computed as offset + the number returned. Present only when truncated — its absence means this page reached the end of what the filter matched. | |
| totalCount | No | Total incidents matching the filter, date range, and match, across all pages, before offset/limit windowing. Present only when the result was truncated. | |
| statuspage_url | No | Status page base URL used. | |
| total_returned | No | Number of incidents in the response. | |
| upstreamCeiling | No | Maximum incidents the vendor's own status API serves in one fetch, present only when that ceiling was reached on this call. It bounds the history independently of limit and offset: incidents older than the oldest one returned cannot be fetched at any offset. On Atlassian Statuspage vendors, since reads past it from the page's history archive, except on a vendor that covers only part of a shared page, such as "sendgrid"; the notice says whether since reaches past it on this call. Absent when the vendor feed is unbounded, returned less than its ceiling, or since was set and the history archive was read back to it (or to its 24-month floor, when since is older). |