Skip to main content
An evidence pack is a fixed record of one calendar month or quarter: each SLO’s attainment and monitoring coverage, the incidents, the maintenance windows and the exclusion windows in that period, and the state of your signed history. Give it to auditors or customers who need a copy that does not change after you send it.
Evidence packs are available on the Business plan and above.

​
Generate a pack

1

Open Evidence packs

In the console, open Reports and select the Evidence packs tab.
2

Pick the period

Under Generate a pack, choose Previous month or Previous quarter. Periods are UTC calendar periods.
3

Preview and generate

The preview shows the figures the pack will hold. Select Generate this pack to issue it. A generated pack never changes.
Each pack in the Packs table can be previewed again and downloaded as PDF or JSON. The JSON download is the pack’s data exactly as it was hashed. The PDF is rendered from the same data and carries it as an attachment.

​
What a pack contains

  • Summary: how many SLOs met and missed their target, the number of incidents and the worst severity.
  • SLO uptime attainment: one row for every SLO in the organization, with its service, the unknown-data policy that applied, and these columns:
  • Incident log: published incidents that started in the period, with their severity and duration.
  • Maintenance windows that overlapped the period.
  • Adjudicated exclusion windows, each with its reason.
  • Tamper-evidence: whether signed history was enabled, its chain head hash and last sequence number, and its latest Bitcoin anchor.
Attainment counts degraded samples as available and unhealthy samples as down. Samples and time inside scheduled maintenance windows and exclusion windows are left out. Figures follow the SLA methodology, version 2.

​
Measured time and coverage

Measured time runs from the start of the period, or from the SLO’s creation when that is later, and leaves out maintenance and exclusion windows. Coverage is the share of measured time that falls in UTC hours with at least one sample carrying a status (healthy, degraded or unhealthy). It does not depend on how often a check reports, so changing a check’s push interval does not change the coverage of a past period. A gap shorter than an hour, inside an hour that has samples, does not lower coverage. Unobserved time is handled by each SLO’s unknown-data policy: counted as down, counted as up, or left out. It weighs as many samples as the check recorded per observed hour in the period.

​
Older periods

Status history is read from individual samples (kept 90 days), then from 15 minute status counts (kept about 400 days), so a pack generated long after its period reports the same figures. When records from the start of the period are no longer held, they were removed under data retention. That is not an outage or a gap in monitoring, so it is not counted as unobserved time: measurement starts at the oldest record Observer still holds. The Measured column shows the later start, and the pack names the SLOs it applies to and explains why.

​
Correct a pack with a revision

A pack is never edited. To correct one, select Regenerate on its row and give a reason. This issues a new revision, computed from the records held at that moment:
  • Revision 2 supersedes revision 1, revision 3 supersedes revision 2, and so on.
  • The new revision records the revision number, the id and SHA-256 of the pack it supersedes, and your reason. Because they are part of its data, its hash covers them.
  • The superseded pack is not changed or deleted. It moves to Superseded revisions, stays downloadable, and can still be checked against its own hash. Anyone you sent it to can compare the two.
  • The PDF of a revision names the pack it replaces and states that, where the two differ, the revision is the corrected record.
Packs generated before schema version 2 keep their original wording, including coverage measured as a share of expected samples.

​
Verify a pack

The SHA-256 shown for each pack, and printed in the PDF footer, is computed over the pack’s data written as JSON with object keys sorted and no spaces. To check it, download the JSON, serialize it the same way, and compute its SHA-256. A match shows the figures have not changed since the pack was generated. When signed history is enabled, Observer records every status change in a hash chain whose entries are signed with Ed25519. The public keys, including retired ones, are published at https://use.observer/.well-known/observer-signing-keys. The chain head is timestamped in Bitcoin through OpenTimestamps.
  • Download the signed history bundle from the Signed history section of the Evidence packs page.
  • Check each entry’s signature against the published keys.
  • Check each confirmed anchor’s proof with the OpenTimestamps client (opentimestamps.org).
Signed history proves when Observer recorded each status, not that a system was up.