Evidence and retention
Window boundaries are real
Section titled “Window boundaries are real”An incident’s SLA window runs from quorum confirmation to confirmed recovery, the same boundaries you were paged on. An exclusion window derived from a discarded false positive is computed per affected region: from the last good check before the incident to the first good check after it. Nothing is stretched to a flattering minute.
What the report counts
Section titled “What the report counts”An incident enters the report if it overlaps the reporting period. Two classes are left out:
- Excluded incidents: downtime you discarded as a false positive. The exclusion is your recorded decision, and counting it in the figures as well would apply it twice.
- Deleted incidents.
Announced maintenance windows that affect the monitor appear in the report as their own class, so a reader sees exactly what was planned and what was not.
Reports carry the events you release
Section titled “Reports carry the events you release”An incident’s timeline in an SLA report contains the events explicitly marked public. Event
visibility defaults to internal, so an event reaches an outside reader once somebody releases
it.
The filter sits in the query that builds the report, which makes it part of every route a report takes. A report exists to leave the house: it goes to customers and auditors. Filtering in the query guarantees that it never carries more than what may go outside.
To show an internal note in customer-facing evidence, mark it public. Everything else stays internal by default.
The math
Section titled “The math”Availability is floored, never rounded up: an SLA figure should be a lower bound you can defend. The sample SLA report shows the full structure with numbers that add up. Hand it to anyone and let them recompute it.
What each history window controls
Section titled “What each history window controls”The plan windows are 7 days (Free), 30 (Pulse), 90 (Sentinel), 365 days (Command), and 730 days (Enterprise). Perstat applies them per data type, each with its own horizon:
| Data or view | Implemented horizon |
|---|---|
| Public history of resolved monitor incidents | Read limit at the plan window. The incident record is not deleted automatically. |
| Raw external probe checks | Physical pruning uses the plan window plus a 2-day technical buffer. |
| Raw host-agent measurement curves | Up to 90 days, on every plan. |
| Status-page uptime history | Up to 365 days, on every plan. |
| Daily rollups, incident and post-mortem versions, activity, and other records | Object-specific lifecycle, independent of the plan window. Some of these records currently have no automatic expiry. |
The Terms separately name a 13-month standard for measurement and event data. This page describes the product’s behavior per data type and does not replace binding terms. Confirm the applicable retention terms through the security review before procurement or deployment.
Export
Section titled “Export”Perstat provides an organization export as CSV with a manifest on request, and self-service export is planned. With a scoped key, the REST API reads monitors, checks, time series, and incidents at any time. For an exit request and the deletion process, use the route on the security page.
Where Perstat fits in assurance work
Section titled “Where Perstat fits in assurance work”Perstat contributes system timestamps, measurements, maintenance, and visible curation to the wider work behind an assurance report or a DORA notification. The report, the filing, and the compliance decision stay with your auditors and your compliance team. The evidence page for leadership describes that division of roles precisely.
- Maintenance and curation: keep planned work and false positives out of the figures, visibly.
- Plans and limits: the history window of each plan.