Response and availability reports

Two reports answer two different questions over an explicit time window: the response report asks how fast your team acknowledged and resolved incidents, and the availability report asks how much of that window your monitors spent healthy, failed, under planned maintenance, or unknown. Your agent reads both through the REST API, the CLI or MCP, and all three compute the exact same numbers — none of them derive the answer independently. There is no reports page in the Console.

Ask your agent

"What were our MTTA and MTTR for severity 1 and 2 incidents last week? List the slowest episodes."

"How available were my monitors over the last 30 days? Which ones have low coverage?"

Job	MCP tool or action	CLI command
Compute the response report	get_response_report	anectico reports response --from <time> --to <time>
Compute the availability report	get_availability_report	anectico reports availability --from <time> --to <time>
Read, write or publish a retrospective	get_incident_retrospective, update_incident_retrospective	anectico incidents retro show, anectico incidents retro edit
Add, complete, reopen or delete a retrospective action item	manage_retrospective_action	anectico incidents retro action add, done, reopen, delete

The response report needs incidents:read. The availability report needs monitoring:read. Both are read-only. Writing a retrospective needs incidents:write.

What your agent gets back

The response report returns the window, the counts, the MTTA and MTTR statistics and the episode rows. The availability report returns the four time buckets, the availability and the coverage for each monitor. Every number is explained below.

Open the proof

The reports themselves have no proof page. Each response-report episode row carries a url for its incident, which opens the incident's proof page at /view/incident/:id. An availability-report row names its monitor; a monitor has no proof page, so ask your agent for its rounds.

Response report

Episodes, not incidents

An incident can be reopened, and every time it is, whatever happened the first time around — when it was first acknowledged, when it was first resolved — used to be overwritten. The response report is built on episodes instead: a fresh episode opens the moment an incident opens, and a reopen opens a new episode rather than rewriting the one before it. So a reopened incident contributes two rows to the report — one for its first response and one for its second — and neither one erases the other.

An incident opened by an alert starts its first episode when the alert triggered, not when Anectico finished processing it, so a delay on our side never shortens a response time. An acknowledgement or resolution is never recorded as earlier than the episode it belongs to.

Each episode row shows:

• the incident it belongs to, and which episode number this is;
• its severity, owning service (if any), and source (alert, error, anomaly, or manual);
• when it opened;
• when it was first acknowledged (later acknowledgements do not move this); and
• when it was resolved, if it has been.

MTTA and MTTR

MTTA (mean time to acknowledge) is the average, across every acknowledged episode in the window, of the time between an episode opening and its first acknowledgement. MTTR (mean time to resolve) is the same average, from opening to resolution, across every resolved episode. Alongside the mean, the report also gives the median and the sample count — the median resists a single very slow (or very fast) episode skewing the picture, and the sample count tells you how much to trust either number. With an even number of samples, the median is the average of the two middle values.

An episode that was never acknowledged, or is still open, is excluded — never counted as zero. A mean built from zeros would silently pull your average down every time someone forgot to acknowledge, or a response is still in progress; instead, the report tells you exactly how many episodes it excluded and why:

• open episodes (never resolved) are excluded from MTTR;
• unacknowledged episodes (never acknowledged — including one that was resolved directly, without ever being acknowledged first) are excluded from MTTA.

If a window's episodes are all open, or all unacknowledged, the corresponding stat reads Unavailable rather than a number: in the API response, its mean_seconds and median_seconds are absent (with available: false), never 0. Unavailable is not the same as zero — zero would mean "instant response," and this platform never invents that.

There is deliberately no per-responder ranking here. A small team's sample sizes make individual comparisons noisy and easy to misread; the report stays at the episode level.

Filters and window

The window is a fixed [from, to) — from is included, to is excluded — of at most 366 days. You can additionally filter by severity, by owning service, and by source. Every filter narrows which episodes are counted; none of them change the formulas above.

The counts, means and medians always cover every matching episode. The episode list shows the newest 1,000 of them; when more matched, the response says so (rows_truncated: true) and the numbers are unaffected.

Availability report

The availability report is duration-weighted: for a window of, say, seven days, it answers "how many of those seven days' worth of seconds were healthy," not "what fraction of checks passed." A monitor that fails for one long stretch and a monitor that fails briefly many times can have the same pass-rate and very different availability.

For each monitor in the window, the report gives four bucket sizes, each in seconds:

• healthy — the monitor was passing;
• failed — the monitor was failing;
• maintenance — a maintenance window covering the monitor was active, whatever the underlying check said (maintenance always wins: a failing check during a maintenance window counts as maintenance, not as failed); and
• unknown — no scheduled check covers that moment at all: before the monitor existed, while it was paused, or in a genuine gap where a check was missed.

Heartbeat monitors are not measured by this report yet: their whole window reads as unknown, so their availability is Unavailable.

Test runs (the ones you trigger by hand to try a configuration) never count toward any bucket.

Availability is healthy / (healthy + failed) — how the monitor did whenever it was actually checked and not under maintenance. When both healthy and failed are zero — nothing but unknown and/or maintenance time in the window — availability is Unavailable, never 0% and never 100% (in the API response, availability is absent and availability_known is false). A monitor with no scheduled checks yet has produced no evidence either way, and the report says so rather than guessing.

Coverage (of this report — a different "coverage" from a monitor's own per-round regional coverage, described in External monitoring) is (healthy + failed + maintenance) / window: how much of the window has an answer at all, whatever that answer was. A monitor with large gaps has low coverage even if every check that did run passed.

If the window you asked for starts earlier than the 90-day observation-history retention boundary, the report tells you the exact instant retention starts (history_retained_from): the portion before it reads as unknown because its rounds have been pruned, not because nothing ran.

The window is [from, to) of at most 90 days, for at most 50 monitors per request. Name the monitors you want, or leave the filter empty for the project's first 50 live monitors (oldest first); if the project has more, the response says so (truncated: true).

Reading a row back to its source

Every response-report row names its incident and carries a link to the incident's proof page, so you can follow it straight to that incident's case file and timeline. Every availability-report row names its monitor, so you can open that monitor's own round history (see External monitoring) to see exactly which rounds produced its healthy, failed, maintenance, and unknown seconds.

CSV export

Both reports accept ?format=csv on their REST endpoint (and a --csv flag on the CLI), which renders the same computed numbers as a downloadable table — one row per episode (up to the same 1,000 as the list), or one row per monitor. For the response report's own numbers, add &part=summary (CLI: --csv-summary): one row with the window, the counts (including the open and unacknowledged episodes each stat excludes), and the mean, median and sample count of MTTA and MTTR.

The CSV is never a second computation: it is the identical typed answer the JSON API shows, formatted as comma-separated values with a header row and standard quoting (RFC 4180). A value the report reports as Unavailable is an empty cell in the CSV, never a literal 0. A title or monitor name that begins with =, +, - or @ is exported with a leading apostrophe, so a spreadsheet shows it as text instead of running it as a formula.

From the CLI

anectico reports response --from 2026-09-01T00:00:00Z --to 2026-09-08T00:00:00Z \
  --severity 1 --severity 2 --service checkout
anectico reports response --from 2026-09-01T00:00:00Z --to 2026-09-08T00:00:00Z --csv > response.csv
anectico reports response --from 2026-09-01T00:00:00Z --to 2026-09-08T00:00:00Z --csv-summary

anectico reports availability --from 2026-09-01T00:00:00Z --to 2026-09-08T00:00:00Z
anectico reports availability --from 2026-09-01T00:00:00Z --to 2026-09-08T00:00:00Z --monitor <monitor-id>

Retrospectives

A retrospective is a written record of what happened, its impact, what contributed to it, what went well, and what went wrong in the response — plus a list of follow-up action items, each with an owner, a due date, and its own open/done state. It has two states: draft and published. Both are readable by everyone who can read incidents in the project; publishing marks the document as final. An action item's owner is shown only to people and keys that can also read your organization's members.

Ask your agent to write or edit it. You read the result on the Retrospective section of the incident's proof page, which is read-only. Each save is checked against the version you last read, the same safeguard every other case-file edit uses: a concurrent edit from someone else is refused rather than silently overwritten. The API's PUT replaces the whole document; the CLI's retro edit and the MCP tool change only the fields you pass and keep the rest. A retrospective can cite up to 100 of its own incident's timeline events as evidence.

An action item's optional ticket link is a reference to a ticket that already exists in whatever system you track work in — Anectico never creates, updates, or posts to it. To make adding an action item safe to retry, send an idempotency_key (CLI: --idempotency-key): repeating the same request with the same key returns the item the first attempt created, and reusing a key for a different item is refused. From the CLI:

anectico incidents retro show <incident-id>
anectico incidents retro edit <incident-id> --expected-revision 0 \
  --summary "..." --impact "..." --status draft
anectico incidents retro edit <incident-id> --expected-revision 1 --status published
anectico incidents retro action add <incident-id> --title "Rotate the leaked credential" \
  --idempotency-key rotate-credential-1
anectico incidents retro action done <incident-id> <action-id>

No retrospective content — neither the document nor an action item's title — is generated or guessed on your behalf. Anectico records exactly what your team writes.