incident.io

List notes attached to an alert. Notes capture context, decisions, and investigation findings against an alert without needing to declare an incident. Each result includes the markdown content, author, and timestamps. Notes the caller cannot see (e.g. due to private-alert access control) are not returned. Content is returned as Markdown. Supported formatting includes headings, bold/italic/strikethrough, inline and fenced code, lists, blockquotes, links, GitHub-flavoured tables, and horizontal rules. Raw HTML, image syntax, task lists, and footnotes are not rendered. Pagination: results are ordered oldest first. Use page_size (default 10, max 50) and pass "next_cursor" as "after" to fetch subsequent pages. Stopping before "has_more" is false means you have incomplete results. Pass "id" to fetch a single note instead of the page. Use alert_note_manage to write, edit or remove a note.

Write, edit or remove a note on an alert. Notes capture context, decisions and investigation findings against an alert without declaring an incident. Actions: - create: add a note to an alert. Takes alert_id and content. - update: replace a note's content. Takes id and content. - delete: remove a note. Takes id. Content is Markdown. Headings, bold/italic/strikethrough, inline and fenced code, lists, blockquotes, links, GitHub-flavoured tables and horizontal rules all render. Raw HTML, images, task lists and footnotes are stripped or rendered as plain text. Only a note's author can edit or delete it. Read notes with alert_note_list.

Resolve one or more firing alerts, marking them resolved now and recording who did it. Use this to close the loop after triage — for example once you've confirmed a firing alert is noise, or the underlying problem is fixed. Use alert_list or alert_show to find alert IDs first. Pass several alert_ids in one call rather than calling once per alert: a batch takes one row lock pass and notifies responders once, where repeated single calls are slower and noisier. Up to 50 per call. Resolving is idempotent — an alert that is already resolved comes back as already_resolved, not an error. Not every alert can be resolved here. Some sources own resolution themselves. For a few (PagerDuty, Opsgenie, BigPanda, Jira, and Wiz when configured for write-back or local resolution) resolving here works as normal. For the rest (ServiceNow, Zendesk, GitHub issues, and Wiz when configured as the source of truth) the alert clears only when that system closes the underlying ticket: those come back as externally_resolved, naming the source. Tell the user to close it there rather than retrying. The response reports every alert you asked about with its own outcome: - resolved: was firing, now resolved - already_resolved: was resolved before this call, nothing changed - externally_resolved: the alert's source resolves its own alerts, so it is still firing - no_permission: you lack the alerts.resolve permission for that alert's team - not_found: no alert with that ID, or you cannot see it - not_resolved: still firing for some other reason (the message says more) Read "resolved" for how many actually changed, and report the exceptions rather than claiming everything was resolved. To resolve the page an alert raised rather than the alert itself, use escalation_respond. Alerts and escalations are separate: resolving an alert does not acknowledge its page.

Look up an alert by ID and return its details. Returns: title, description, status, deduplication key, alert source (with type), priority, tags, links (source, dashboard, silence), any linked incidents, and the external links attached to it, and the alert groups it is in. Each alert group gives its ID and title, when the alert joined, how many alerts it holds, and how the alert joined: by the route's grouping keys, or by AI grouping with the model's outcome and reasoning. The reasoning is shared by the alerts the model decided together. Use 'include' to request additional sections: - payload: the raw JSON payload from the alert source (only available for firing alerts) The response includes linked incident IDs. Pass these to incident_show with include: ["investigation"] to see the full investigation for each linked incident.

List configured alert sources for this organisation. Returns the ID, name, and source type (e.g. datadog, sentry, grafana, http) for each alert source. Use alert source IDs to filter alert_list results by source. This is not paginated — alert source lists are typically small.

Count alerts grouped by one or more dimensions, returning aggregate statistics. Use this tool instead of paginating through alert_list when you need counts, breakdowns, or trend data across many alerts — for example "how many alerts by source this week?" or "what proportion of alerts result in incidents?" Dimensions (combine freely in the group_by array): - status: group by status (firing, resolved) - priority: group by alert priority (e.g. Critical, Urgent, In-hours) - source: group by alert source name (e.g. Sentry, Grafana, Datadog) - has_incident: group by whether the alert is attached to an incident (true/false) - has_related_escalations: group by whether the alert raised an escalation (true/false), as the alert list's "Has related escalations" filter does. An alert that joined a group another alert had already escalated for counts as false. - team: group by the org's configured team. Resolves the team alert attribute, so its counts agree with filtering alerts by team. Multi-value: alerts tagged with several teams are counted under each; untagged alerts show as "None". - tag: group by alert tags. Multi-value: alerts carrying several tags are counted under each; untagged alerts show as "None". Archived tags are ignored, so an alert whose only tags are archived is counted under "None". Scoping to a team: use the team filter for exact teams, or team_part_of to include a parent team and all its sub-teams in the hierarchy (e.g. a "Go To Market" parent covering Sales, Marketing, etc.). Combine team_part_of with group_by ["team"] to break a parent down into its sub-teams. Scoping to tags: use the tag filter with alert tag names to include alerts carrying any of those tags. - attribute:<attribute_id>: group by any alert attribute's value (e.g. team, service, environment). Read config://organisation to find attribute IDs. Array attributes are flattened so each value is counted individually; catalog-typed attributes are resolved to names. - week: group by ISO week (e.g. 2026-W03) - month: group by calendar month (e.g. 2026-01) - quarter: group by calendar quarter (e.g. 2026-Q1) Each group includes a count, a workload breakdown (responder time from linked incidents, split by working hours, late evening, and overnight), and sample alert IDs that you can pass to alert_show for detail. This lets you answer "which alert sources generate the most on-call work?" directly. Note on workload scope: workload is summed from all incidents linked to the alerts in each group, regardless of when those incidents were created. This means an alert created in December linked to an incident from November will include November's workload. This is intentional — it measures the total impact generated by the alert — but means alert workload totals may differ from incident_stats workload for the same date range. By default, alerts caught by maintenance windows are excluded. The tool processes at most 25,000 alerts, the newest first. If more match, the response sets "truncated": true, and the team and has_related_escalations filters only see those 25,000 — narrow the date range for accurate results. Conversion rate: to calculate what proportion of alerts become incidents, group by ["source", "has_incident"]. For each source, conversion rate = count(has_incident=true) / total count. Sources with low conversion rates are noise candidates. Noise that escalated: the noise tag marks alerts as noise, so filter with tag: ["noise"] and has_related_escalations: true, and group by ["source"] or ["team"] to see where noise that reached someone comes from. Group by ["tag", "has_related_escalations"] for the full split. Cross-reference: use incident_stats(group_by: ["alert_source"]) to see how alert sources map to incident volume and workload over time. This traces the full path from alert noise through to responder cost. Note that alert counts will be higher than incident counts for the same source, since multiple alerts can link to the same incident. Deeper analysis: many organisations have a small number of alert sources (e.g. one Datadog integration) but rich alert attributes (team, service, environment, feature). Group by attribute:<attribute_id> to break volume, conversion and workload down by these — for example group_by ["attribute:<service_id>", "has_incident"] to find the noisiest services, or group_by ["team"] for per-team alert load. Read config://organisation to discover attribute IDs. Use alert_list when you need to browse the individual alerts behind a number. Structured analysis: for a comprehensive report with playbooks, themes, and recommendations, call analysis_start first — it provides step-by-step methodology and a branded report template. Use this tool directly only for quick, focused queries.

Add, remove, or replace tags on up to 50 alerts. Use alert_list or alert_show to find alert IDs. Tags must already exist; this tool never creates them. Every organisation has a tag called noise. Adding it marks the alert as noise, the same as the Mark as noise button. Choose operation add to keep existing tags and add these, remove to keep all tags except these, or set to replace the complete tag set. An empty set clears every tag. References are validated before any alert changes. If any alert or tag is unknown, the whole call fails with alerts_not_found or tags_not_found and nothing is changed. Otherwise each alert reports updated, too_many_tags, or no_permission.

List the organisation's active alert-tag vocabulary. Alert tags are names responders apply to alerts after they arrive (for example "noisy" or "known issue"). This tool returns the live vocabulary — archived tags are excluded. Each result is an id and name only; it does not include how often a tag is used. Use this to discover tag IDs and names. Pass a query to filter by name substring. Pagination: results are ordered by name, case-insensitively. Use page_size (default 25, max 50) and pass "next_cursor" as "after" to fetch subsequent pages. Stopping before "has_more" is false means you have incomplete results.

Start an operational analysis session. Returns a download URL for a tar.gz archive containing everything needed to run analysis: playbooks with step-by-step methodology, your organisation's configuration (severity IDs, custom fields, roles), reference materials, and a branded HTML report template. Call this before any analytical or reporting work — "analyse my incidents", "prepare for the review", "how are we doing?" — rather than querying ad hoc: the playbooks it downloads carry a staged methodology. Download and extract the archive, then follow the playbook steps using the MCP data tools (incident_stats, alert_stats, escalation_stats, etc.).

Ask the incident.io AI agent a question about your organisation's incidents, on-call schedules, alert routes, and operational setup. Use this tool for conversational questions that need reasoning, entity resolution, or multi-step investigation — for example "what happened on my last on-call shift?", "summarise recent incidents for the payments team", or "who is on call for the backend service?". The agent can query schedules (including past shifts and overrides), search incidents, look up catalog data, and manage schedule overrides. Pass incident_id to focus the agent on that incident, with its full investigation data and management tools: it can update the incident, create follow-ups, escalate, and draft status updates — for example "what caused this incident?" or "draft a status update for stakeholders". It may act on the incident to satisfy the request, so for a purely-read question prefer incident_show with include: ["investigation", "postmortem"]. For structured data needs (counts, filtering, pagination), prefer the direct tools: incident_stats for analytics, incident_list for browsing, incident_show for details. The ask tool adds latency and cost from the inner LLM call, so only use it when you need the agent's reasoning. Pass session_id from a previous response to continue a multi-turn conversation.

List entries in a catalog type with optional search and pagination. Catalog entries are instances of a type — for example, entries in a "Service" type might include "Payments API" or "User Auth". Each entry has attribute values defined by the type's schema, and may have aliases (alternative identifiers like owner/repo for GitHub repos). Required: catalog_type_id (the ID or type_name of the catalog type — use catalog_type_list to discover available types). Use identifier for an exact ID, external ID or alias lookup; the entry name only works when the type's use_name_as_identifier is true. Search is fuzzy and does not prove an alert value resolves exactly. The response includes the type's attribute schema alongside entries. Attribute values use attribute names as keys. Reference attributes (those pointing to other catalog types) are formatted as "Name (ID)" so you can read the name directly and use the ID to look up the referenced entry via catalog_entry_show if needed. A reference to an archived entry reads "Name (Archived) (ID)": the value is still stored, but the entry it points at is no longer active. attribute_filters narrows entries by their stored reference attributes, and several filters AND together. To find what depends on an entry or what a team owns, use {"attribute_id": "<referencing attribute>", "operator": "one_of", "entry_ids": ["<target ID, external ID or alias>"]}. To partition ownership, use operator is_blank for entries with no value and is_set for entries with any stored value, including a reference to an archived owner. A one_of target that resolves to no active entry is an error, not proof that nothing points to it. Pagination: entries are ordered by name (or rank for ranked types). Use page_size (default 25, max 250) and pass "next_cursor" as "after" to fetch subsequent pages. Stopping before "has_more" is false means you have incomplete results. For a total across all pages, request include_total_count; it is omitted on timeout or when an attribute filter is used.

Look up a catalog entry by ID and return its full details. Returns the entry with all attribute values and aliases — unlike catalog_entry_list, array attributes are not truncated. The response includes the type's attribute schema for context. Aliases are alternative identifiers for the entry (e.g. owner/repo for GitHub repos). Use this when you need the complete set of values for a specific entry, e.g. all members of a team or all dependencies of a service.

List catalog types configured in this organisation. The catalog is a connected map of your organisation's data — it contains types like Service, Team, Feature, Customer, and anything else relevant to your organisation. Each type has a schema of attributes that define what data its entries hold. Use this tool to discover what types exist, then use catalog_entry_list to browse entries of a specific type. Returns: name, type_name, mode, registry_type, is_editable, use_name_as_identifier, description, and the attribute schema (excluding derived attributes like backlinks and paths). Type-level management fields report what is configured. An omitted registry_type does not prove that no external API job updates this type's entries. An attribute's mode describes that field, not the source of its type. This lists schemas, not entries. No type's entries are searched by this tool; to claim a type has no matching entries, query that type with catalog_entry_list and page to completion. A search of another type does not establish absence here. This is not paginated — organisations typically have a manageable number of catalog types.

List change events: the deploys, feature flag flips, config changes, infrastructure and database changes, and alerts that bots announced in the organisation's indexed Slack channels. Newest first. Use it to answer "what changed just before this started?". Each row has the event's ID, title, type, state (in_progress, done, cleanup, failed), when it happened, the channel, the source system and its link, who made the change, and the structured metadata extracted from the message (for a deploy: repository, components, environments, commits and pull requests; for a flag: its name, previous and new state, environment). An event that re-posted in its thread, like an alert reminder, is one row with repeat_count and last_seen_at. A deploy row also carries code_changes_count, the merged code changes linked as shipped by it. Pass an ID to change_event_show for the full message, the thread and the code changes. Filters: - occurred_after / occurred_before: the window, at most 31 days. When occurred_after is omitted it is the 24 hours before occurred_before (or before now), and the response echoes the window it used, so widen occurred_after if you need more - change_types and states: one or more values each - channel: a Slack channel name or ID - source_provider: the source system, e.g. launchdarkly - query: words that must all appear in the title, message or metadata, e.g. a service or flag name Pass next_cursor as 'after' to fetch the next page. There is no total count: while has_more is true the rows you have are a partial set, so narrow the window or the filters rather than paging through a long history. Events only exist for bots posting in channels the organisation indexes, so an empty list means nothing was announced there, not that nothing changed. For merged pull requests, which code_change_list covers, use that instead.

Look up one change event (a deploy, feature flag flip, config, infrastructure or database change, or alert that a bot announced in an indexed Slack channel) with everything we know about it. Find it by the ID a change_event_list row or a code change's deploys gave you, or by the link to its Slack message. A link to a reply that repeated or updated the event resolves to that event. Returns: title, type, state (in_progress, done, cleanup, failed), when it happened, when its message was first posted and last repeated, how often it repeated, the channel and Slack link, the bot that posted it and who made the change, the source system and its link, the message as posted, and the structured metadata extracted from it (for a deploy: repository, components, environments, commits, pull requests and head_sha; for a flag: its name, previous and new state; 'errors' lists what extraction could not read). 'parent' is the earlier event this one continues, e.g. the deploy start for a deploy finish, and 'thread' any other changes posted in the same Slack thread. For a deploy, 'code_changes' lists the merged code changes linked as shipped by it, with how each link was made; pass an ID to code_change_show for the change itself. Read its note before concluding a deploy shipped nothing: links come from the commits, pull requests or tags the deploy message named, or from comparing its head commit with the previous deploy's.

List the conversations the user has had with the incident.io agent in the incident.io dashboard, most recently active first. Use this when the user wants to carry on a dashboard conversation here, such as "continue my incident.io chat about checkout latency". Find it by title with query, or by the incident it was about with incident_id, then pass its thread_id to chat_thread_show to load it. Each conversation comes with its title, the opening of the user's first message, when they last asked something, and the incidents it was about. Only the user's own conversations are listed.

Load a conversation the user had with the incident.io agent in the incident.io dashboard, so you can carry it on here. Returns the conversation as markdown: each message, the steps the agent took to answer it, and the sources its replies cited. Sources carry IDs you can pass to other incident.io tools, and telemetry sources carry the query that was run. Only the user's own conversations can be loaded. Very long conversations leave out their earliest messages.

Create a cover request asking for volunteers to cover a shift. By default the system identifies candidates from the schedule's rotation members and notifies them directly; pass candidate_user_ids to ask specific people instead — e.g. just the one person the requester named. The requester receives a summary tracking candidate responses. The request is created on behalf of the authenticated user, who must be on call during the requested window — you can only ask for cover of your own shift. Requires user authentication (e.g. OAuth) rather than an API key. Times must be UTC RFC 3339 ending in Z; never convert a wall-clock time by writing an offset yourself. Prefer this over schedule_override_create when someone asks for cover rather than instructs a change: a cover request asks first, an override changes who gets paged immediately.

List cover requests: asks for someone else to take a stretch of an on-call shift. Use this to find the cover request ID that cover_request_respond and cover_request_manage need — e.g. "remind people about my cover request" or "accept Milly's request" starts here. Only current and future requests are returned (a request whose window has fully passed is no longer actionable). By default only pending ("created") requests show; pass state to see accepted, declined, or cancelled ones. Pass user (a user ID, or "me" for the caller) to narrow to requests that user raised or is a candidate for, and schedule_id to narrow to one schedule. Each result carries the request's window, state, message, candidates with their response state, and — for partially covered requests — which ranges are covered and which still need someone.

Manage a cover request as its requester or creator. Actions: - cancel: cancel the request. Only works while it is still pending (nobody has accepted yet). - accept_offer: accept a candidate's partial coverage offer, creating an override for the offered ranges. Requires candidate_user_id. - send_reminder: nudge candidates who haven't responded yet. Only the requester or creator can manage a request, so this requires user authentication (e.g. OAuth) rather than an API key.

Respond to a cover request you are a candidate on. - accept: accept the full request. An override is created automatically so you are placed on call for the requested window. - decline: decline the request; you are removed from consideration. - offer: offer partial coverage for specific time ranges. The requester then accepts or declines your offer. The response is attributed to the authenticated user, who must be a candidate on the request. Requires user authentication (e.g. OAuth) rather than an API key. Offer time ranges must be UTC RFC 3339 ending in Z.

Create a native Insights dashboard from a set of organised charts and tiles. Call insights_chart_options first. Use preset_key whenever a preset fits the request: it carries valid organisation-specific defaults. Use chart only for a combination that is not already a preset, starting from a preset's chart in insights_chart_options. Add a trend or KPI tile by its key from the tiles list. Each chart and trend tile becomes a full-width row, and KPI tiles next to each other share a row, grouped under the supplied section heading. The result is a normal native dashboard that the user can open and refine with the visual editor. When the request names a team, custom field value, or anything else to filter by, find it in insights_chart_options. If nothing matches, tell the user what you looked for and the closest options that exist, and ask before you create the dashboard. Never drop a filter the user asked for without telling them. This creates the dashboard immediately. Call it only after the user has asked for a dashboard and the requested contents are clear; ask a focused question first when an important grouping, time range, or metric is ambiguous. Returns a direct link to the created dashboard.

Look up which values a custom field accepts, so you can set it to a real one. Call this before setting a custom field on incident_create or incident_update. Pass custom_field_id — either the field's ID or its exact name — and optionally a search term to narrow a long list. You do not need to know the field's type first: this handles every type. There is no cursor here. When pagination.has_more is true, pass a search term to narrow the list rather than asking for the next page. Each value comes back with an id and a human-readable value. The id is what you set: the response's set_using tells you which key of a custom_field_entries value to put it in (value_option_id for option fields, value_catalog_entry_id for catalog-backed ones). Read the field's own flags before writing to it: - can_be_set is false when an expression fully derives the field. Setting it will fail, so don't try. - allows_new_values is true when the field is tag-like, so people can add values to it. You can still only set a value that appears in this list. - accepts_multiple tells you whether you may set several values at once. Text, link and numeric fields configure no values at all. They return an empty list with a note, which is not the same as an option field that has no options configured. For catalog-backed fields with a fixed filter, fixed_filter names the reference attribute and configured target entries that restrict options. The values list is the actual permitted subset; an organisation config preview of the backing catalog type is not an authoritative option list. This is the best way to find the values a custom field accepts.

Describe the panels and variables of a dashboard before calling dashboard_query. This reads metadata without rendering images, executing panel queries, or calling a model. Missing metadata is reported explicitly.

Fetch dashboard evidence at the panels, variables and time bounds you choose. Call dashboard_describe to discover panels and saved variable selections. Omitted variables use saved selections, which the result identifies. Use arrays for multi-value selections. An empty panel_ids returns an overview image without executing numerical queries. Numerical evidence is available only for supported metric targets; unsupported targets return explicit reasons. It contains underlying query results before panel transformations, summaries and bounded samples. Targets with outputs execute their complete query group and identify calculated results by family_key. Scalar values cover the full requested window and have no sample timestamp. Separate widget formula context is not calculated; do not present its input values as the displayed calculation. Before interpreting a target, check whether its metric meaning, unit or aggregation window is unclear. If so, read its datasource's returned guidance path unless already read this session. Batch independent guidance reads. Use read_file for mounted paths, or telemetry_guidance_show on MCP. Guidance can describe metric semantics, not prove causality or dashboard transformations. If guidance is missing or does not establish the meaning, keep that uncertainty explicit; do not guess or query again just to obtain semantics. Read image references with read_images. Successful image delivery does not validate chart contents. Rendering and numerical retrieval fail independently; inspect their statuses. Explicit RFC3339 time_from, time_to and purpose are required. Refresh the tool schema if you previously supplied only a natural-language query. No planner or analyser runs here. Supported log targets return log_events or typed tables instead of metric series. Inspect fetched and returned counts and output limits; aggregate rows have no invented sample timestamp. Logs and tables share this call's worker and response budgets.

Search for dashboards based on service names, metrics, and contextual information. ## Query Format Provide comprehensive search context including: - Dashboard name or theme (if known) - Service or component names - Metric types you're interested in (error rates, latency, CPU, memory, etc.) - Environmental context (production, staging, region) - Any other identifying information - Include specific technical detail in your query parameter, including tags or parameters as key=value pairs if known (e.g. service=auth, endpoint_method=Login). ## Examples - "Kubernetes pods CPU and memory usage for service=auth in production" - "Database performance dashboard for PostgreSQL with query latency and connection pool metrics" - "API Gateway dashboard showing request volume and error rates for environment=us-east-1" The search will match against dashboard names, descriptions, tags, and panel titles to find the most relevant dashboards for your query.

List the configuration that uses a resource: workflows, alert routes, alert sources, escalation paths, custom fields, policies, incident templates and anything else that refers to it in a condition, expression or parameter. Use this to answer "where is X used?" or "what would break if I deleted X?". It's the same check the dashboard runs before letting someone delete or archive a resource. Identify the resource by its engine resource type and ID: - Alert attribute: resource_type "AlertAttribute", id is the attribute ID (the organisation config resource lists alert attributes with their IDs) - Severity: "IncidentSeverity"; status: "IncidentStatus"; incident type: "IncidentType"; incident role: "IncidentRole" - Custom field: "CustomField"; custom field option: "IncidentCustomFieldOption[\"<custom field ID>\"]" with the option ID - Catalog entry: "CatalogEntry[\"<catalog type ID or type name>\"]" with the entry ID (catalog_type_list gives the type name) - Workflow: "Workflow"; alert route: "AlertRoute"; alert source: "AlertSourceConfig"; escalation path: "CatalogEntry[\"EscalationPath\"]"; schedule: "CatalogEntry[\"Schedule\"]" Each result says whether deleting the resource would clean it up automatically (can_be_auto_deleted) or whether it has to be changed first.

Search the organisation's synced knowledge base documents — runbooks, guides, post-mortems, architecture notes and similar — indexed from sources like GitHub, Notion, and Confluence. Two matching modes are supported, and you can pass both for higher recall: - queries: natural-language questions or phrasings, matched semantically against document content - keywords: specific names, terms, or identifiers, matched against document summaries Returns compact summaries (id, title, generated summary and tags, source system and URL), not full content. Matches are sorted alphabetically by URL — judge relevance from the summaries and tags, not the order. Each match may list refers_to: other indexed documents it links to, worth considering as follow-up reads. Pass a result's id to document_show to read its full content. Use this to find operational knowledge, e.g. the runbook for a failing system or what a past incident concluded. This covers the organisation's own documents only, and not incident.io's own product documentation — it will not tell you how an incident.io feature behaves or how to configure one.

Read a document from the organisation's synced knowledge base, returning the full text content (typically markdown) alongside its title, generated summary and tags, source system, and URL. Name the document by its ID from document_search, or by its file path when it is a file in a synced plugin: either under the plugin's mount (/plugins/<plugin>/runbooks/lock-wait.md) or relative to the plugin root (runbooks/lock-wait.md). Source URLs are not accepted. Very large documents are cut at a size cap, signalled by content_truncated; the source URL links to the complete document. Use this once search has surfaced a promising document and you need its actual content, e.g. to follow runbook steps or quote a post-mortem. Use 'include' to request additional sections: - notes: problems recorded against the document by incidents and by assessed skill loads, newest first. Each note says what the document gets wrong, quotes the passage it is about, proposes an edit, and carries a status: open, or likely_resolved when the quoted passage is no longer in the text. Use them to decide what to fix in a runbook. A note's skill_usage_ids are the loads that produced it; pass the document to extension_skill_usage_list to see every load that worked from it.

Aggregate incident duration metrics (e.g. time to acknowledge, time to resolve) grouped by one or more dimensions, returning per-group statistics. Use this for MTTX-style questions — "what's our median time to resolve for P1s this quarter?", "how has time to acknowledge trended by month?", "which team resolves incidents fastest?". Each group reports count, mean, p25, p50 (median), p75, p90, min, and max, all as durations in hours. Dimensions (combine up to 2, at most one time bucket): - metric: which duration metric the numbers belong to (e.g. Time to resolve vs Time to acknowledge). Group by this whenever more than one metric is in play, otherwise different metrics are pooled into one meaningless number. - severity: group by severity level (e.g. Critical, Major, Minor) - week / month / quarter: group by time bucket (bucketed by incident report time) - custom_field:<field_id>: group by a custom field's values (read config://organisation to find field IDs) By default all configured duration metrics are included — pass duration_metric_ids to restrict to specific ones. Zero-length durations are excluded, and each metric honours its own paused-time configuration, matching the MTTX dashboard. Date range: durations are measured over incidents reported within the window. Supply created_after / created_before derived from the question; if omitted the window defaults to the last 90 days. A very wide window over a large organisation can time out — narrow the range if that happens. By default test and tutorial incidents are excluded and declined/canceled/merged incidents are excluded. Provide explicit status_category or mode filters to override these defaults. Cross-reference: use incident_stats for counts and workload (this tool is about how long incidents take, not how many there are), and incident_list with include: ["durations"] to see per-incident durations behind a group.

Raise an escalation to page a specific user or an escalation path. The words "escalate" and "page" are synonymous. Escalations wake people up and cannot be undone. Paging the wrong person, or paging when nobody asked you to, is the worst mistake this tool can make, so it drafts by default. # Choosing an action * action=suggest (the default) — draft an escalation for a person to accept, edit or decline. Use it whenever the request was implicit, the target is uncertain, or the target is an escalation path. * action=execute — page immediately. Only when the user explicitly asked for someone to be paged AND you have exactly one unambiguous user ID. To page a draft a human has already reviewed, pass action=execute with only suggestion_id — it is applied verbatim. Anything ambiguous — an escalation path, several users, or paging whoever asked — is drafted for confirmation instead of paged. * action=edit_suggestion — revise a draft. Pass suggestion_id plus only the fields you want changed; anything omitted keeps the draft's value. A user and an escalation path are alternative targets, so setting either one clears the other. # When not to use it * Information requests: "who's on call for payments?", "which teams can I page?". Answer those with escalation_path_list, schedule_show or catalog_entry_list. Naming who you could page is fine; paging them is not. * Changing who is on call. This tool cannot edit a schedule or an escalation path. * Something you can't do but a human could. The answer is never to page someone; say what you can't do. # Parameters * Give exactly one of user_ids or escalation_path_id. Never both, never neither. Prefer a user ID when you have a specific person in mind. * incident_id is optional — an escalation can stand alone. With an incident, title defaults to the incident's name; without one, title is REQUIRED, because the person paged needs to know what for. * description is required, and should say what expertise or action is needed. Keep names, incident numbers and priorities out of it. Good: "Database performance issue requires your PostgreSQL optimisation expertise". * Pass real ULIDs only. If you cannot find the ID you need, ask rather than guessing, and never fall back to a fuzzy match. # What a draft does From a chat thread the draft is posted as a card in the conversation. From any other caller it is created without a card, so show it to the user yourself and find it again with suggestion_list; a person can accept it from the dashboard. card_posted on the result tells you which happened. A draft whose card lives in a conversation must be edited there, in Slack or the dashboard.

List escalations (also known as "pages") with optional filters, newest first. Use this for anything about pages that have already happened: "why was I paged?", "how many times was I paged last night?", "has that page been acked?", "find the page a teammate sent me". Pass user: ["me"] when someone asks about their own pages. Each result includes the escalation's ID, title, status, priority, escalation path, who raised it, who was paged, when it was acked and the acker's user ID, the linked alert and incident, and whether it paged you and you acked it. Use escalation_show for full details on a specific escalation. Filters (all optional): - query: search escalation titles - status: one or more of pending, triggered, acked, resolved, expired, cancelled, snoozed, pending_repeat. What each means: - pending: created but nobody has been paged yet - triggered: someone is currently being paged and hasn't responded - acked: someone acknowledged the page and is handling it (stops it climbing the path) - resolved: the page is done (acked and closed out, or the linked incident/alert resolved) - expired: nobody acknowledged before the escalation path ran out of levels to try - cancelled: called off before it completed - snoozed: temporarily silenced, to re-trigger later - pending_repeat: acknowledged but set to page again after a delay (a repeating reminder) - escalation_path: one or more escalation path IDs - priority: one or more priority IDs (see config://organisation for IDs) - user: one or more user IDs, or "me" for the caller - incident: one or more incidents, as INC-123, 123 or an incident ID - alert: one or more alert IDs - created_after / created_before: bound the time range Use page_size to set the page length (default 15, max 50). Pass "next_cursor" back as "after" to fetch the next page.

List escalation paths configured in this organisation. Escalation paths define who gets paged and in what order when an alert fires or someone manually escalates. Each path has levels — level 1 is paged first, then level 2 if nobody acknowledges, and so on. Use escalation_path_show to see the full ladder with who is currently on call at each level. You can search by name. Pagination: results are ordered by name. Use page_size (default 15, max 50) and pass "next_cursor" as "after" to fetch subsequent pages. Stopping before "has_more" is false means you have incomplete results.

Look up an escalation path and show who would be paged at each level. Shows the full escalation ladder, resolving schedules to their current on-call users. Each level also names the schedules it pages (and the rotation, when it pages just one), which answers "which paths use this schedule". When the path has conditional branches (e.g. different paths for different priorities or working hours), all branches are shown with the currently active branch marked. Each level's condition lists every branch that leads to it, and the path's working-hours windows are returned with their timezone. Level 1 is paged first — if nobody acknowledges within the time-to-ack window, level 2 is paged, and so on. Use this to answer questions like "who would get paged if this alert fires?", "what does the backend escalation look like?", or "who's first-line on-call for this path?" Use schedule_show to see the full rotation details for any schedule referenced in the path. Use escalation_stats(group_by: ["path"]) to see paging volume and ack rates for this path over time.

Respond to an active escalation (page) on behalf of the authenticated user. Use escalation_list to find active escalations, then respond with: - ack: acknowledge the page — stops it from climbing the escalation path. Use when you or an agent are handling the issue. - nack: decline the page — the escalation continues to the next level. Use when you cannot handle it. Returns the updated escalation with its new status. Requires user authentication (e.g. OAuth) rather than an API key, because the response is attributed to a specific user.

Look up an escalation (page) by ID and return its details. An escalation is what happens when someone gets paged — it tracks who is being notified, whether they've acknowledged, and the full history of the page. Returns: title, description, status, priority, escalation path, creator, linked incident and alert IDs, who is being paged (targets with urgency), the full state transition history — including who acknowledged it, by name, and when — and whether it paged you and you acknowledged it.

Count escalations (pages) grouped by one or more dimensions, returning aggregate statistics with workload from linked incidents. Use this tool instead of paginating through escalation_list when you need counts or trend data — for example "how many pages per escalation path this week?" or "what's our ack rate?" Dimensions (combine freely in the group_by array): - status: group by outcome (pending, triggered, acked, resolved, expired, cancelled, snoozed). "Cancelled" means the page was automatically cancelled because the underlying alert resolved or was attached to an incident — it is system-initiated, not user-initiated. Exclude cancelled from ack rate calculations. - priority: group by priority (e.g. Critical, Urgent, In-hours) - path: group by escalation path name (e.g. "Engineering", "SRE On-call") - team: group by the team that owns the escalation path. Resolves through escalation path ownership, so its counts agree with filtering escalations by team. A path owned by several teams is counted under each; escalations on a path with no team owner show as "None". - user: group by the user(s) who were paged. Shows user names. An escalation can target multiple users across different levels, so the same escalation may appear under multiple users. Useful for assessing individual on-call burden. - time_of_day: group by when the escalation was created in UTC — working_hours (09:00-18:00 Mon-Fri), late_evening (18:00-23:00 any day + weekend daytime 09:00-18:00), or overnight (23:00-09:00) - week: group by ISO week (e.g. 2026-W03) - month: group by calendar month (e.g. 2026-01) - quarter: group by calendar quarter (e.g. 2026-Q1) Scoping to a team: use the team filter for exact teams, or team_part_of to include a parent team and all its sub-teams in the hierarchy. Both resolve through escalation path ownership. Combine team_part_of with group_by ["team"] to break a parent down into its sub-teams. Key metrics to derive from the results: - Ack rate: to calculate, group by ["path", "status"] then compute resolved / (resolved + expired) per path. Low rates indicate paging fatigue or coverage gaps. - Out-of-hours load: group by time_of_day to see working_hours vs late_evening vs overnight split. Overnight pages with low ack rates are the highest priority to fix. - Path comparison: group by path to see which teams are paged most - Workload per group: each group includes responder-hours from linked incidents, split by working hours, late evening, and overnight Each group includes a count, workload breakdown, and sample escalation IDs that you can pass to escalation_show for detail. The tool processes at most 25,000 escalations. If more match, the response sets "truncated": true — narrow the date range for accurate results. Cross-reference: use alert_stats(group_by: ["source"]) to see which alert sources drive the most pages, and incident_stats(group_by: ["severity", "month"]) to see how paging load correlates with incident volume. Together the three stats tools give a full picture: alerts → pages → incidents → workload. Structured analysis: for a comprehensive report with playbooks, themes, and recommendations, call analysis_start first — it provides step-by-step methodology and a branded report template. Use this tool directly only for quick, focused queries.

List the organisation's extension connectors — the MCP servers and HTTP APIs connected through Extensions — with their capabilities and connection health. Each entry says what the connector can be asked for (its capabilities, after runtime restrictions) and whether the connection currently works: connection_status is the latest diagnostic verdict, and reconnection_reason is set when it needs re-authentication. The tools field names the operations enabled in the connector's access policy. Use this when reviewing an organisation's Extensions estate: what's connected, what's broken, and what a new integration would add.

Load a plugin from a source-control repository as an extension, and start its first sync. A plugin is a skill tree — a directory holding skills/<name>/SKILL.md files, optionally with a README and reference files — that incident.io's AI agents mount and draw on during investigations and chat. Point this tool at the repository (and subpath, when the plugin isn't the repository root) and the plugin is registered with every skill enabled, then synced. The repository must be reachable through the organisation's connected GitHub or GitLab integration; that isn't checked here. The first sync runs asynchronously and verifies it within moments — check the plugin's sync_status via extension_plugin_list, where an inaccessible repository or malformed plugin shows up as a sync_error. Renaming, disabling, skill selection, and removal are managed from the dashboard's Extensions page.

List the organisation's extension plugins with their skills and sync state. Extension plugins are skill trees (SKILL.md files) synced from the organisation's own source-control repositories and mounted into incident.io's AI agents, so the agents follow the organisation's runbooks and conventions during investigations and chat. Use this tool to see which plugins are installed and which skills each provides. To see how a plugin's skills are performing — and what our assessments say their authors should fix — pass a plugin's ID or name to extension_skill_feedback_list.