# Response and availability reports

> How fast your team acknowledges and resolves incidents, and how available your monitors were, over a fixed window.

Canonical page: https://anectico.com/docs/respond/response-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](/docs/agents/proof-pages) 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](/docs/respond/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](/docs/respond/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

```bash
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:

```bash
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.