Observer Docs

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.
SLO burn	Error budget burn events inside the window, and each SLO’s budget at the start and end. See Incident SLO impact.
Observed by	The Observer Agents and the outside-in locations 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 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 (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 (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.

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.

In the Evidence panel, download it as JSON or PDF. From the API or an MCP client, call GET /incidents/{id}/evidence (exportIncidentEvidence, scope read:incidents) with format=json (the default) or format=pdf. Every export is recorded in the audit log 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:

{
  "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, 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.

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.

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.

Quickstart

Concepts

Guides

Notifications

MCP server

CLI

Reference

Troubleshooting

Incident evidence

The evidence appendix

Add the measured impact to an update

AI drafts

Signed evidence export

What it contains

Classification

Verify an export

Mapping to DORA and NIS2 reports

NIS2 (significant incident reports)

Limits

​The evidence appendix

​Add the measured impact to an update

​AI drafts

​Signed evidence export

​What it contains

​Classification

​Verify an export

​Mapping to DORA and NIS2 reports

​DORA (major ICT-related incident reports)

​NIS2 (significant incident reports)

​Limits

The evidence appendix

Add the measured impact to an update

AI drafts

Signed evidence export

What it contains

Classification

Verify an export

Mapping to DORA and NIS2 reports

DORA (major ICT-related incident reports)

NIS2 (significant incident reports)

Limits