Manage incidents and on-call

All responder configuration writes use the server preview and confirmation flow in both MCP and the CLI. Discover the action with list_write_actions, call its declared door without confirm_token, and review the complete before, proposed, required scopes and external audience. After approval repeat identical arguments, adding the returned token. CLI commands omit --confirm-token for preview and repeat with it to apply; there is no local --yes bypass.

Responder configuration creates require a stable idempotency_key in MCP or --idempotency-key in the CLI. Keep it identical in preview, confirmation and retry. Identical creates return the first committed result; a different request under the same key is refused. One-time signing and heartbeat secrets are withheld on durable replay. Updates of schedules, contact methods, escalation policies and channels require the exact current updated_at as expected_version / --expected-version. Incoming-source edits and secret rotations require the current positive source version in that field. Template versions and catalog and monitor revisions keep their numeric fences. A conflict needs a new read, preview and approval.

Use an incident when a problem needs coordination, explicit ownership, or a durable timeline. A single Issue can often be handled directly without declaring an incident.

Your agent sets up on-call schedules, escalation policies, the response catalog and runbooks, and it declares and updates incidents, through MCP or the CLI. You open an incident's proof page to check the case. Contact methods and notification channels are set in the Console.

Use link_incident_signal after creating an incident to attach error or trace evidence. The link action is available over MCP.

Every plan

Incident response, on-call schedules, escalation policies, response services and runbooks are on every plan. Plans differ only in limits, never in which features you can use.

Ask your agent

"Create a weekly on-call schedule for the platform team, then an escalation policy that pages the on-call person first and the whole team after 10 minutes."

"Declare a severity 1 incident called Checkout unavailable. Link issue <issue-id> and the checkout service, then give me the incident link."

Job	MCP tool or action	CLI command
Create, read, change or delete an on-call schedule	create_oncall_schedule, get_oncall_schedule, list_oncall_schedules, update_oncall_schedule, delete_oncall_schedule	anectico oncall schedules create, get, list, update, delete
Find who is on call at a time	resolve_oncall	anectico oncall now <schedule-id>
Add or remove an override	create_oncall_override, delete_oncall_override	anectico oncall overrides create <schedule-id>, anectico oncall overrides delete <override-id>
Manage escalation policies	create_escalation_policy, list_escalation_policies, update_escalation_policy, delete_escalation_policy	anectico escalation create, list, get, update, delete
Manage response-catalog services	create_response_service, list_response_services, get_response_service, update_response_service, delete_response_service	anectico service-catalog create, list, get, update, delete
Check where a service key would page now	preview_alert_routing	anectico service-catalog preview
Manage runbooks	create_runbook, list_runbooks, get_runbook, revise_runbook, list_runbook_revisions, delete_runbook	anectico runbooks create, list, get, revise, revisions, delete
Declare an incident	create_incident	anectico incidents create <title>
List incidents or read one case file	list_incidents, get_incident	anectico incidents list, anectico incidents view <incident-id>
Acknowledge, resolve or reopen	set_incident_status	anectico incidents acknowledge, resolve, reopen
Change the title, description or severity	update_incident	anectico incidents update <incident-id>
Comment, attach evidence, link or unlink a signal	comment_incident, add_incident_evidence, link_incident_signal, unlink_incident_signal	anectico incidents comment, evidence, link, unlink
Read ownership or toggle a checklist step	get_incident_ownership, set_incident_checklist_step	anectico incidents ownership <incident-id>, anectico incidents checklist <incident-id> <step-id>
Work an incident in Slack	create_incident_slack_channel, get_incident_slack_channel	anectico incidents slack create, link, show
Follow a timeline as it grows	get_incident, read again	anectico incidents watch <incident-id>
Delete an incident	delete_incident	anectico incidents delete <incident-id> --yes

Incident, response-catalog and runbook reads need incidents:read. Declaring or changing needs incidents:write; opening also needs channels:read so its preview can show the enabled notification channels before confirmation. Responding (comment, evidence, status, link, checklist) needs incidents:respond, and deleting needs incidents:delete (unlinking a signal also needs it). Escalation policies use escalation:read, escalation:write and escalation:delete. On-call schedules use oncall:read, oncall:write and oncall:delete, together with members:read and projects:read; contact methods use oncall:contacts:write. A response service also needs alerts:rules:write because each service binds one alert rule. The MCP write tools preview first and apply on a second call with a confirm_token; see MCP tools.

What your agent gets back

get_incident returns the incident's case file: its version, ordered timeline, evidence and linked signals. anectico incidents view also reads delivery receipts when authorized. A lifecycle write must quote the current version, so read the case file just before you change it. Every incident row from list_incidents and get_incident, and the target of a write receipt such as create_incident, carries the link to the incident's proof page in its url field when the key can name the project.

Delivery receipts say which channels were notified, so reading them needs channels:read as well as incidents:read. Without it anectico incidents view still returns the incident, with an empty deliveries list and a redactions entry that names deliveries and that scope: the receipts were withheld, which is not the same as nothing having been sent. An empty deliveries with no such entry means no receipt exists. get_incident does not carry receipts today; read them with anectico incidents view or get_notification_delivery.

Open the proof

Open the url from the result. It opens the incident's proof page at /view/incident/:id. The page is read-only, it names its project, and it has one action, Copy link. It shows the incident's status and severity, the attributed timeline (latest first, with a chronological order), the response plan with the assignee, the captured ownership and checklist, linked signals, evidence, notification receipts, the Slack channel and the retrospective. A banner shows when a response is waiting for a linked alert and whether it is pending, retrying, or failed. The page changes nothing: to act, ask your agent.

Prepare on-call

Before relying on escalation:

1. add personal contact methods. In the Console, open Connections and notifications (/connections), choose the Notifications tab, and use My contact methods. See Connect tools and notification delivery;
2. create an on-call schedule;
3. add rotations and any temporary overrides;
4. create an escalation policy; and
5. send a test through the complete route.

Keep schedule ownership current. An escalation policy cannot compensate for stale contact methods.

Build an on-call schedule

Ask your agent to create a schedule with the timezone where its handoffs should be interpreted. A schedule has layers. Add members to a layer in rotation order, choose the rotation length and start time, and use active-window restrictions when a layer covers only particular days or hours. Rotation lengths must be positive whole seconds representable by the server; fractional or overflowing protobuf durations are rejected. A layer has no on-call member before its start time.

Schedules and overrides belong to one project. Anectico accepts only current members of the same organization in rotation layers and overrides; if membership cannot be verified, the change fails closed. An inactive schedule never resolves an on-call person and cannot page through escalation.

Layers stack: a later active layer overrides an earlier one. To check coverage, ask who is on call now with resolve_oncall (CLI: anectico oncall now <schedule-id>; add --at for a specific handoff time). The answer carries the time it was checked. A missing responder at that time is different from an unavailable or restricted read; it does not describe continuous schedule coverage.

Rotation anchors and override boundaries are interpreted in the schedule or layer's selected IANA timezone, not in the timezone of the machine that sends the request. Anectico rejects a wall time that does not exist during a spring-forward gap or occurs twice during a fall-back fold; choose an unambiguous time instead. For a repeatable handoff check, give resolve_oncall a fixed instant (an RFC3339 time with an offset). A layer with no timezone of its own follows the schedule timezone.

Use an override for a dated coverage change such as leave or a shift swap. Set both start and end; the underlying rotation resumes when the override expires. Override windows are half-open ([start, end)) and may touch, but overlapping windows on the same schedule are rejected so coverage never depends on an ambiguous winner.

Create escalation policies

Ask your agent to create ordered levels. Each level waits its configured delay, then notifies one or more channels, members, or on-call schedules. Every level needs at least one target. The first level's delay counts from when the alert fires (or resumes), so a first-level delay gives responders a window to acknowledge before anyone is paged; set it to 0 to page immediately. Each later level's delay counts from the previous level, and a repeat waits the repeat interval before starting again at the first level.

Use later levels to broaden the audience when an alert remains unacknowledged. Repeating escalation requires a repeat interval and an additional-passes limit (max_escalations). For example, a limit of 3 allows the initial pass plus up to 3 more passes through the route. Configured routes are not delivery receipts. Attach the policy to an alert rule and test the complete route. If a policy is deleted, rules using it fall back to their own notification channels. Once an alert starts escalating, its levels, delays, repeat settings, and targets are frozen for that run; editing, shrinking, deactivating, or deleting the policy affects only future alerts. Acknowledgement and resolution are terminal for the running escalation.

Escalation policies belong to one project. Policy lists, reads, edits, deletes, alert-rule routing and on-call schedule targets are scoped to that same project; a policy ID from another project is treated as not found. A target ID must refer to a member, channel or schedule that can be verified; free text is not accepted.

An update replaces the whole definition: a level left out of the update is deleted. Read the policy or schedule immediately before you change it, and avoid changing the same record at the same time as another person, because these updates do not detect concurrent changes.

Set up the response catalog

The response catalog answers "who owns this, through which policy, with which checklist" before an alert ever fires. Ask your agent to add a service: a stable key (the same key your alerts, monitors, or an incoming-alert source name), a name, and the escalation policy it pages through. An on-call schedule and a default runbook are optional. Each service binds exactly one alert rule; creating it fails if the escalation policy does not exist, is inactive, or has no levels, and nothing is left half-created. A service key is unique among your project's live services. Delete a service to free its key for reuse. Each project has a capacity limit; see service and runbook limits.

An external monitor can be owned by a service: give it the service's key and its failures page through this service's escalation policy instead of a policy of its own, and every incident they open carries this service's ownership and runbook. Deleting a service leaves the monitors it owned unable to page until you give them another service or their own routing.

Use preview_alert_routing (CLI: anectico service-catalog preview --service-key <key>) to check where an alert naming a given key would go right now, before you rely on it. It reports whether the key resolves to a live service, whether a fallback key was used, who is on call, which runbook revision an incident would snapshot, and an explicit reason when it would not page: unknown key, no routing coverage, nobody on call, or no runbook. Call it again to recheck the same key.

A runbook is a versioned checklist: up to 50 steps, each with a title, optional markdown detail, and up to 5 reference links. Links are references to open during an incident, never commands Anectico runs. Revising a runbook writes a new immutable revision; a service's default runbook always points at the runbook, and each incident that opens for it copies whichever revision is current at that moment. Editing the runbook afterward never changes an already-declared incident's checklist.

Declare an incident

When an Issue triggers the response, ask your agent to declare the incident from that Issue. Anectico carries the Issue link into the new case file. The title should be a short customer-facing symptom. The CLI supports these choices:

anectico incidents create "Checkout unavailable" \
  --description "Customers cannot complete payment" \
  --severity 1 \
  --link-type error_group \
  --link-ref <issue-id> \
  --service-key checkout

Supported incident links are alert, error_group (Issue), and anomaly. Add another supported signal with anectico incidents link <incident-id> --type <type> --ref <signal-id>. Use the linked Issue to reach affected customers, traces, replays, releases, and external tickets.

Naming --service-key (or passing service_key to create_incident over MCP) declares the incident against that response-catalog service and snapshots its owner and runbook at the moment the incident opens, the same as an automatically opened one. See Ownership and checklist below. An unknown or deleted key is refused. An incident opened automatically when a cataloged service's alert escalates carries that same ownership snapshot with no extra step. Read it back with anectico incidents ownership <incident-id> (below).

Anomaly findings are promoted automatically. The case file preserves the detector explanation, expected band, observed value, score, non-content labels, and detection time even if the original finding is later removed. Labels named after recorded-content conventions and the detector's opaque series key are not copied into the case title or durable snapshot.

Work from the case file

The case file starts with its attributed timeline. Linked issue impact is labeled as the issue's full history, rather than a total for the incident window. Supporting evidence, linked signals, notification receipts, Slack information, and the retrospective sit with the case on its proof page. The retrospective keeps the case summary and structured review together without combining their records.

Assigning a responder is separate from acknowledging an incident. Your agent can hand an incident to a current teammate, or clear the responder. This needs incidents:respond, not incidents:write. Preparing the change needs incidents:read; a nonempty current or proposed responder also needs members:read.

Read get_incident or anectico incidents view ID -o json first and copy its exact project, incident UUID and decimal-string version. Prepare through execute_external_action:

{"action":"assign_incident","arguments":{"incident_id":"INCIDENT_UUID","project_id":"PROJECT_UUID","assigned_to":"MEMBER_UUID","expected_version":"7"}}

The preview changes nothing. It shows current and proposed responders, observed version, current membership, and that a linked external responder channel may be updated. Review it, then repeat identical arguments with confirm_token from structuredContent.preview. Changed state, a departed target, unavailable membership or hidden prior responder refuses the change. A departed prior teammate is identified by the stored UUID and its disposition, without an invented current name.

anectico incidents assign INCIDENT_UUID --to MEMBER_UUID --expected-version 7 -o json
anectico incidents assign INCIDENT_UUID --clear --expected-version 7 -o json

Choose exactly one of --to and --clear. Repeat the chosen command after review with --confirm-token TOKEN. Clear sends an explicitly present empty assigned_to; omission is invalid. Assignment-only PATCH /api/v1/incidents/ID uses this same confirmed path. Mixing assignment with title, description, severity or retrospective is refused. Use the exact snake_case assignment field names shown above.

An applied receipt identifies the authenticated actor, requested_version and post_state_available. Its subject target carries the committed after_version and changes with /assigned_to, alongside the incident proof link and effective project. Read the case again to verify current assignment and version. MCP omits a hidden assignment and names its members:read redaction; the native case file reports assigned_to_withheld: true. An explicit empty assignment means unassigned. Clearing an actually empty assignment does not need a roster lookup. Assignment and its history are teammate control records, not a new tracked-customer relation, and follow the incident's organization and project deletion.

An optional stable idempotency_key (--idempotency-key) can recover original mutation metadata within the ten-minute retry cache. Recovery reports outcome: replayed and the original versions, assignee and receipt metadata. Recovery checks current incident read authority and member visibility before disclosing the original result; the receipt is not current state. Beyond that cache, a consumed version conflicts. A lost response does not establish failure: retain the same request and key, read back before deciding, and never substitute a new version in an old confirmed request. Generic durable recovery is not promised. The stored change and queued consequence do not prove notification delivery.

Slack's Assign to me button also remains available in the pinned summary (see Work an incident in Slack).

Record material changes as timeline comments (comment_incident, CLI: anectico incidents comment):

• what customers are experiencing;
• current impact and affected scope;
• evidence supporting the working cause;
• mitigation and rollback actions; and
• decisions that change the response.

Ask your agent to gather cited evidence from the Issue, traces and replays, then link the relevant underlying objects rather than pasting an unsupported summary.

Attach evidence (notes, URLs, logs, traces, metrics, replays, screenshots, or documents), and keep the retrospective in the case file. Comments and evidence from teammates are append-only, so simultaneous responders do not overwrite each other. If somebody changes incident metadata or lifecycle state after you read the case file, Anectico reports a conflict and asks you to read the refreshed case file instead of silently replacing their update. The notification receipts section records each durable incident email, Slack, and webhook delivery attempt and its final status.

The CLI exposes the same strict case file. Read it immediately before a mutation, then reuse the returned version and one stable retry identity:

anectico incidents view <incident-id>
anectico incidents watch <incident-id> --timeout 30m --output json
anectico incidents acknowledge <incident-id> \
  --expected-version <version> \
  --idempotency-key ack-<incident-id>-v<version>
anectico deliveries list --incident <incident-id>

The incident watcher emits a current snapshot followed by newly appended timeline events as newline-delimited JSON. Each record carries an opaque resume cursor. After interruption, restart with --cursor <last-processed-cursor>; Anectico verifies the cursor against the same project, incident, event ID, and database sequence before emitting anything newer. It fails if that resume point is absent or changed rather than silently skipping chronology. Temporary transport, HTTP 408/429, and 5xx failures reconnect with bounded exponential backoff and put degraded or recovered state on stderr, leaving stdout safe for an NDJSON consumer. Existing timeline entries are skipped unless you pass --include-existing; that fresh-history option cannot be combined with a resume cursor.

Keep the same idempotency key when retrying the exact same request. This holds for acknowledge, resolve, and reopen, and equally for adding a comment or attaching evidence. Anectico returns the first successful response and does not add a second timeline, evidence, or notification event.

Requests are compared by value, not by the exact bytes you sent, so re-serializing an identical retry is safe: a different key order, 1e2 where you first sent 100, 2.0 where you first sent 2, or different whitespace all still replay. A number sent as a string is a real change, and so is any change to a value a reader of the case file would see.

Change anything about the request and reuse the key, and you get 409 Conflict with nothing written — a different comment body, a different evidence artifact, different transition fields, or the same key sent by a different user or API key. A new key with an old version conflicts too. Nothing is silently replaced, and a retry can neither hide another responder's change nor hand you their original response. If you get this 409, your write did not happen: read the incident back and retry from its current state. Which key to use depends on which conflict you hit — reuse of a key with changed content needs a new key, while a stale version needs the same key with the current version. The message says which.

For an organization-level credential, set --project or ANECTICO_PROJECT; project-scoped credentials remain pinned to their signed project. MCP clients can use the get_incident tool for the equivalent strict read, and reach resolve_oncall and list_notification_deliveries through execute_read_action.

Evidence links can be Anectico root-relative paths or absolute HTTP(S) URLs. Anectico rejects protocol-relative links and executable schemes such as javascript: and data:.

Ownership and checklist

An incident tied to a cataloged service carries an immutable ownership snapshot — the service, its owner schedule, escalation policy, and the default runbook's revision at the moment the incident opened — plus a checklist of that runbook's steps. An incident is tied to a service when it opens from one of the service's alerts (an incoming alert routed to it, or a failure of a monitor it owns) or is declared naming the service. Later edits to the service or the runbook never rewrite an already-open incident's snapshot; the next incident for that service picks up the change. An incident with no cataloged service — a manually declared incident that named no --service-key, or one opened by an alert rule no service owns, such as a monitor with its own escalation policy — has no ownership panel on its proof page.

Toggle a checklist step as the response proceeds; toggling it back to the state it already has records nothing new. Every toggle is attributed and timestamped on the incident timeline.

anectico incidents ownership <incident-id>
anectico incidents checklist <incident-id> <step-id> --done
anectico incidents checklist <incident-id> <step-id> --undone

Reading or toggling a checklist step on an incident with no ownership snapshot fails; a project-scoped credential reading an incident outside its own project gets the same not-found response as an incident that does not exist. MCP clients reach the same data with get_incident_ownership and set_incident_checklist_step.

Incidents opened from an alert

An incident opened from an alert shares its response with that alert: the alert's acknowledgment is what stops escalation. Acknowledging or resolving such an incident — with anectico incidents acknowledge/resolve, through the REST API or with the MCP set_incident_status tool — records the command and applies it to the linked alert, attributed to you. Because it acts on the alert, it needs alerts:acknowledge (to acknowledge) or alerts:resolve (to resolve) in addition to incidents:respond; every member role has both, but a narrowly scoped API key without them gets 403. The incident's status changes when the alert commits it, usually within seconds. Until then every incident read carries pending_response:

state	Meaning
pending	Sent (or about to be sent) to the alert; waiting for it to commit.
retrying	The alert could not be reached; Anectico keeps retrying with backoff. last_error and next_attempt_at say why and when.
failed	The alert refused the command or retries ran out. Nothing was acknowledged; act on the alert directly.

The response returns 200 with the incident at its new version but its previous status; read the incident again to see it converge. Acknowledging the alert directly converges the incident the same way, and whichever acknowledgment commits first is the one recorded. If the alert resolves while an acknowledgment is pending, the incident resolves and the acknowledgment is dropped — a late acknowledgment never reopens a resolved alert. Reopening an incident is local to the case file and does not reopen or re-arm its alert. Incidents without a linked alert keep their own lifecycle.

Work an incident in Slack

Open a Slack channel for an incident to give a responder team a pinned, always-current summary and one-click acknowledge, resolve, and assign-to-me buttons — without anyone leaving Slack.

Ask your agent to create a new channel for the incident or link one that already exists, choosing which connected Slack workspace to use. Creating twice is safe: an incident keeps at most one linked channel, and asking again returns the one it already has rather than opening a second. The one exception is a channel that stopped working — archived or deleted in Slack, or unreachable because the Slack app lost a permission. Asking again then retries: it reuses the channel if it still exists, and otherwise opens a new one (or links the channel you name).

Once linked, the channel gets a pinned summary (title, severity, status, and assignee) with the buttons the incident's current status allows. People appear by their linked Slack account; someone without a linked account is shown as an Anectico user without a linked Slack account.

• Acknowledge and Resolve apply the same transition anectico incidents acknowledge/resolve would, attributed to whichever Anectico user your Slack account is linked to.
• Assign to me assigns the incident to that same linked user.

An open incident shows all three buttons; an acknowledged one shows Resolve and Assign to me. A resolved incident shows no buttons — the summary says who resolved it and when instead ("Resolved automatically" when its alert resolved it). Reopening is done from the incident itself (ask your agent), not from Slack; once reopened, the summary shows all three buttons again.

The pinned summary — and a short note in the channel — updates automatically as the incident is acknowledged, resolved, reopened, reassigned, or commented on from any surface (CLI, REST, MCP, or Slack), so the channel never goes stale.

If your Slack account is not linked to an Anectico user, clicking a button gets you a private message asking you to link it first — no action is taken silently on your behalf. Clicking a button without the required permission (or, for an incident that shares its response with a linked alert, without permission to acknowledge or resolve that alert) is refused the same way, privately, with the reason. So is a click the incident can no longer accept — for example, when someone else acknowledged or resolved it first — with a private reply such as "This incident is already acknowledged.", "This incident is already resolved." or "This incident is no longer available."; the pinned summary is never changed by a refused click.

The CLI reaches the same three actions:

anectico incidents slack create <incident-id> --connection-id <connection-id>
anectico incidents slack link <incident-id> --connection-id <connection-id> --channel-id <channel-id>
anectico incidents slack show <incident-id>

If Slack shows the channel but buttons stop working or a new channel won't open, the Slack connection likely needs to be reinstalled — the app now asks for three more permissions (managing and reading channels, and pinning messages) than an older install granted. In the Console, open Connections and notifications (/connections). There the Slack connection is labeled Reinstall needed rather than the generic "Needs reauth" shown for other providers. Reinstall it, then ask your agent to create or link the channel again to resume it. get_incident_slack_channel (CLI: anectico incidents slack show) reports the channel's state, so you can tell a channel Slack could not reach from a missing permission.

Close deliberately

Resolve the incident when customer impact has ended and monitoring confirms recovery. Capture any remaining follow-up work in the linked ticket system. Reopen the incident if the same impact returns before the response is complete. Reopening never overwrites the response history the first time around — see Response and availability reports for how that history is reported.

Once the incident is settled, write a retrospective from its case file: what happened, its impact, what contributed to it, what went well and went wrong, and a list of follow-up action items. See Retrospectives for the full workflow, including how to publish it and track its action items from the CLI.

Verify the response path

Schedule a safe test window, confirm the expected member is on call, trigger a test alert, and verify the correct escalation levels stop after acknowledgement. Acknowledge once from the alert and once from its incident: both must stop the next escalation step, and a notification still queued when you acknowledge must not be sent. Test again after changing rotations, provider connections, or contact methods.

• Connect tools and notification delivery
• Alerts or integrations are not delivering

Escalation level delays and repeat intervals must be valid protobuf durations representable by the server. Severity filters and weekly restriction types are normalized before storage so accepted case and surrounding whitespace do not change matching behavior.

The full schedule read includes every restriction's type and start and end day and time. Resolving an instant evaluates starts, restrictions and rotation position in the owning resolver. The response returns the selected user and proven override provenance; it omits a winning layer when that provenance is unavailable. MCP get_escalation_policy and CLI escalation get return the complete policy definition. Repeating escalation requires a positive finite maximum; zero is never unlimited paging. A zero repeat interval disables repeats and requires a zero cap.

Contact updates preserve omitted type, value, label and position. An explicit position of zero moves a method first; an empty label clears it. Changing a destination resets its verification. Channel updates also preserve omitted mutable fields; omitted webhook URL or headers retain the stored credentials.

Pause and resume require the monitor’s current configuration revision. Verify or remove a custom domain using its current updated_at as expected_version / --expected-version. Signing-secret rotation uses the incoming source’s current positive version as expected_version / --expected-version. Checklist changes require the incident’s incident_version from ownership detail as expected_revision / --revision. A stale version needs a new read and preview.

Schedule, contact-method, escalation-policy, service, runbook and runbook-revision lists are pages. MCP accepts limit and cursor; the CLI accepts --limit and --cursor. Use the returned continuation token with the same filters. The default page is 100 entries, the maximum is 500, and counts describe returned entries.

The full MCP schedule definition carries an override page separately. Pass limit and cursor to get_oncall_schedule to continue it; overrides_truncated explicitly marks omitted earlier or later overrides. CLI oncall overrides list accepts the same continuation with --limit and --cursor. The schedule layers and restrictions remain complete on every page.

Catalog service deletion and an unfinished rule-release retry use the external action door. Releasing the owned rule resolves its active alerts and linked incidents and can send recovery notifications. Review the displayed current and proposed alert and incident states and recovery channels; the preview requires alerts:read, and channels:read when an active alert exists, alongside the service permissions. Attached incident Slack channels are named; event endpoints remain private to their owning credentials.

A responder-channel preview shows the selected connection, current linked channel and the complete proposed create, link, and post-and-pin request. Read the connection and destination before approving. Native channel commands use the same server confirmation token.

Manual incident creation requires a stable idempotency_key in MCP or --idempotency-key in anectico incidents create. Both show the complete proposal, service and runbook snapshot, required permissions and current notification channels. After approval, repeat unchanged arguments with the confirmation token. Matching retries recover the original metadata receipt without notifying again. A primary signal association leaves the declaration's source as manual.

Incident metadata changes require the exact current version from get_incident or anectico incidents view in the JSON body as expected_version. MCP assignment, metadata, status and comment inputs all use exact nonzero decimal strings, such as "7"; copy the returned version without converting it through a floating-point number. A stale version requires a new read, preview and approval.

Incident and alert-rule lists return a page count and owning continuation. Use MCP limit/cursor or CLI --limit/--cursor with unchanged filters. Incident totals are absent unless counted by the owner. Alert-rule reads also page the workspace active silences separately with silences_cursor. Acknowledgment reads return the current retained snapshot, not all past transitions.

Declared account value

Use get_incident_account_value_impact or anectico incidents value-impact INCIDENT_ID for one union of linked error activity. That guide owns selectors, permissions, coverage, monetary interpretation and the live incident proof card. It also explains when an incident cannot supply a monetary measurement.

Versions and approval

Comment, evidence and signal-link additions preview the exact addition first. Repeat the same arguments with confirm_token (CLI: --confirm-token) to apply. Reuse the same retry key for a comment or evidence attachment. Concurrent observations merge. Deleting an on-call schedule, override, contact method, escalation policy or notification channel, and testing a stored channel, require expected_version (CLI: --expected-version) from the current updated_at. Override deletion uses its parent schedule timestamp. Template deletion uses the current integer version. If another edit wins, re-read and review a new preview after the conflict; never substitute a new version into an old approval.