> ## 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. # Evidence packs > Generate a fixed record of SLO attainment, coverage, incidents, maintenance and exclusions for a closed month or quarter, correct it with a new revision, and check it independently. 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. > [!NOTE] > > 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: | Column | Meaning | | - | - | | **Measured** | **Full period**, or **From** a date when measurement started later in the period (see below). **Not measured** for an SLO created after the period ended. | | **Coverage** | The share of measured time the check was reporting, with the observed and measured hours, and the number of excluded samples. | | **Target** | The SLO's target. | | **Attainment** | Truncated to three decimal places, never rounded up. | | **Result** | **Met** or **Missed**. Exactly on target is met. | * **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](/docs/concepts/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](/docs/concepts/slos-and-error-budgets#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](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](https://opentimestamps.org)). Signed history proves when Observer recorded each status, not that a system was up. ## Related * [SLA methodology](/docs/concepts/sla-methodology) * [SLOs and error budgets](/docs/concepts/slos-and-error-budgets) * [Incident evidence](/docs/guides/incident-evidence) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.