> ## Documentation Index
> Fetch the complete documentation index at: https://docs.use.observer/llms.txt
> Use this file to discover all available pages before exploring further.

# Incident evidence

> The measured record behind an incident (impact window, services, customers, SLO burn, related changes, observers, coverage), the AI drafts grounded in it, and the signed evidence export.

Observer computes an **evidence appendix** for every incident from its own
records: when your checks actually went bad and recovered, what was
affected, and how well the incident was observed. The appendix is computed
in code, never by AI. It appears in the incident editor, grounds the AI
drafts, and is the core of the signed evidence export.

## The evidence appendix

Open an incident in the console. The **Evidence** panel under the form
shows:

| Row | What it shows |
| - | - |
| **Measured impact** | The impact window: from the first status change to degraded or unhealthy until every check that went bad is healthy again, with its duration, its worst status, and how many separate periods it had. Status changes are the dwell-gated ones, so short blips that never changed status do not count. When no check changed status, the incident's own times are used and the panel says so. |
| **Checks** | The checks behind the affected services (through their SLOs) and the check that opened the incident automatically, if any. |
| **Services** | The services the incident marks as affected. |
| **Customers** | Customers marked as affected, and the customers who can see an affected [customer-scoped page](/docs/guides/customer-scoped-pages). |
| **SLO burn** | Error budget burn events inside the window, and each SLO's budget at the start and end. See [Incident SLO impact](/docs/concepts/incident-slo-impact). |
| **Observed by** | The Observer Agents and the [outside-in locations](/docs/guides/outside-in-checks) that observed the checks. |
| **Locations** | Per-location results for outside-in checks: each location's latest status and when it reported, how many of its results counted as failing, how many were not healthy out of all its results, and the rule that turns location results into the check's status. |
| **Data coverage** | The share of expected samples that arrived during the window, based on each check's interval. Low coverage means the record has gaps. |
| **Related changes** | Deploys and other [change events](/api/change-events/post-change-events) recorded around the start of the window. |

Related changes are listed **by timing only**. Observer does not decide
that a change caused an incident, and nothing in the appendix says so.

To read the same appendix from the API or an MCP client, call
[`GET /incidents/{id}/impact`](/api/incidents/get-incidents-by-id-impact)
(`getIncidentImpact`, scope `read:incidents`).

### Add the measured impact to an update

When you post an incident update, you can tick **Add the measured impact
summary**. Observer appends a short summary of the measured window to the
public message, in the language of the incident's pages. It is off by
default and is computed again on the server when you post, so it always
matches the evidence at that moment.

## AI drafts

**Draft with AI** in the incident editor drafts the next customer update
from the incident and its evidence. Postmortem drafts end with the
evidence appendix. A person always reviews the draft before anything is
published.

The model sees a customer-safe summary of the evidence: the window,
whether it is ongoing, the duration, the worst status, counts, location
names and data coverage. It does not see ids, check names, customers,
SLOs, agents or related changes.

Every draft is checked against the evidence before you see it. A draft is
refused, and you get no draft, when it:

* contains an internal identifier;
* states a cause that no operator update has stated;
* contains numbers that are not in the incident or its evidence;
* says the issue has recovered while the evidence shows it ongoing (unless
  you are writing a Resolved update);
* says customers are still affected after a measured recovery on a
  resolved incident.

Agents can request the same draft with
[`POST /incidents/{id}/draft`](/api/incidents/post-incidents-by-id-draft)
(`draftIncidentUpdate`, scope `write:incidents`). It **never publishes**:
it returns the draft (or `null` with a `reason`) together with the
evidence, and a person posts the update.

## Signed evidence export

On the Business plan and above, you can export a signed record of an
incident. Use it for internal reviews, auditors, regulators or customers
who need a fixed copy of what happened.

<Note>
  The signed evidence export is rolling out and is enabled with a release.
  Until it is enabled, the download buttons do not appear and
  `GET /incidents/{id}/evidence` (`exportIncidentEvidence`) returns `404`.
  The evidence appendix and AI drafts work as described above.
</Note>

In the **Evidence** panel, download it as **JSON** or **PDF**. From the API
or an MCP client, call
[`GET /incidents/{id}/evidence`](/api/incidents/get-incidents-by-id-evidence)
(`exportIncidentEvidence`, scope `read:incidents`) with `format=json`
(the default) or `format=pdf`. Every export is recorded in the
[audit log](/docs/reference/audit-log-events) with its digest.

### What it contains

* detection time and whether monitoring or an operator detected it;
* the classification you set (optional, see below);
* opened, published and resolved times;
* the measured impact window and duration;
* affected services, checks and per-location results, with the rule that
  turns location results into the check's status;
* counts of affected customers (see below);
* the public update timeline;
* notification receipts;
* related changes (timing only), SLO burn and data coverage;
* the postmortem link, and notes on the method.

Notification receipts are minimized. Operator alerts and subscriber
notifications appear as counts per channel and status. Each subscriber
appears as a masked address and a `recipient_hash`: the first 32
hexadecimal characters of `sha256("<incident id>:<address in lowercase>")`.
A subscriber can compute it to confirm they were notified, and the hash
differs between incidents. The full address is never included.

Customers appear as counts only: how many customers were marked as
affected, and how many can see an affected customer-scoped page. Customer
names are not included in the export. They stay in the
evidence appendix.

### Classification

In the **Evidence** panel you can record a classification for the
incident. It is a free-text label in your own words, up to 64 characters.
The console suggests **Minor**, **Major** and **Critical**, and you can
type anything else. Observer records who set it and when, and includes it
in the export. The classification is your decision: Observer never
proposes a regulatory category, and the label is not a determination
that an incident is "major" or "significant" under any framework.

### Verify an export

The JSON export is an envelope:

```json theme={null}
{
  "payload": { "kind": "observer.incident_evidence", "...": "..." },
  "sha256": "...",
  "signature": "...",
  "signing_key_id": "...",
  "signature_alg": "...",
  "verify_url": "https://use.observer/reliability/verify"
}
```

`sha256` is the digest of the canonical JSON payload, and `signature` is
an Ed25519 signature over it. Anyone can check both at
[use.observer/reliability/verify](https://use.observer/reliability/verify),
the same page that verifies SLA statements. Changing any field in the
payload makes verification fail. The PDF prints the digest, the key id
and the verify address in its footer.

## Mapping to DORA and NIS2 reports

The table below shows which export fields help with the incident reports
that DORA (Regulation (EU) 2022/2554, Article 19) and NIS2 (Directive (EU)
2022/2555, Article 23) ask for.

<Warning>
  This is a mapping to help the people who write those reports find the
  facts Observer recorded. It is not a claim that the export, or Observer,
  makes anyone compliant with either framework. The report, the
  classification decision, the impact assessment and the submission to
  the competent authority remain yours. Check the current text and your
  national authority's template before relying on any row.
</Warning>

### DORA (major ICT-related incident reports)

| Report section (summary) | Export fields that help |
| - | - |
| Initial notification: date and time of detection and of classification | `incident.detected_at`, `incident.classification.classified_at` |
| Initial notification: description of the incident | `incident.title`, `timeline` |
| Initial notification: classification criteria triggered | Not provided. `incident.classification.label` is your own wording; whether the criteria are met is your assessment. |
| Intermediate report: number of clients affected | `affected.customers.marked_affected_count`, `affected.customers.with_access_to_affected_page_count` (customers recorded in Observer) |
| Intermediate report: duration and service downtime | `impact.start`, `impact.end`, `impact.duration_minutes` |
| Intermediate report: services and functions affected | `affected.services`, `affected.checks` |
| Intermediate report: geographical spread | `affected.locations`, `affected.location_verdict_rule` (where the service was observed failing, not where clients are) |
| Intermediate report: communication to clients | `timeline`, `notifications.subscriber_notifications` |
| Final report: root cause | Not provided. Observer does not determine causes. `related_changes` lists changes by timing only. |
| Final report: resolution and recovery time | `incident.resolved_at`, `impact.end` |
| Final report: lessons learned, measures taken | `incident.postmortem.url` |

### NIS2 (significant incident reports)

| Report stage (summary) | Export fields that help |
| - | - |
| Early warning: that a significant incident occurred, when it was detected | `incident.detected_at`, `incident.classification` |
| Incident notification: initial assessment, severity and impact | `incident.severity`, `impact`, `affected` |
| Incident notification: indicators of compromise | Not provided |
| Intermediate or progress report on request | `timeline`, `notifications` |
| Final report: detailed description, severity and impact | `incident`, `impact`, `affected`, `slo_burn` |
| Final report: type of threat or root cause | Not provided (see `related_changes`, timing only) |
| Final report: mitigation measures applied and ongoing | `timeline`, `incident.postmortem.url` |
| Final report: cross-border impact | `affected.locations` (observation points, not a statement of cross-border impact) |

### Limits

State these plainly in any report that uses the export:

* The impact window is what Observer's checks measured. It does not cover
  parts of a service no check observes.
* Customer counts are the customers recorded in Observer, not every person
  who uses the service. The export carries counts only.
* The classification label is whatever you typed. It is not a
  determination that the incident is "major" or "significant" under
  either framework.
* Locations are where Observer's outside-in checks ran, not where users
  are.
* Observer does not determine root causes. Related changes are listed only
  because of their timing.
* Status changes are read from the audit log and kept for your
  organization's audit log retention. Export the evidence while it is
  kept.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.