Availability you can hand to a regulator.

A regulator does not ask whether you felt available. It asks when the incident began, how long the service was down, and how you know. Perstat produces the availability evidence behind those answers, measured from outside your service and confirmed across regions. It produces the evidence; it does not make you compliant.

Two clocks run during an outage at a regulated firm. One is the outage. The other starts the moment you classify the incident as major, and under DORA that clock is a legal object: an initial notification within 4 hours, an intermediate report within 72 hours, a final report within one month. Neither clock waits for you to go find the data. Either the record of when the service went down exists, measured and timestamped as it happened, or it does not.

Perstat produces the availability half of that record. It does not file the report, and it does not make you compliant. What it does is make sure that when the examiner asks how long you were down, the answer is already measured, already timestamped, and confirmed from more than one place on earth.

What the examiner opens first

Strip a DORA incident notification or a supervisory questionnaire down to its availability questions and they are blunt: When did the incident begin, not when someone noticed it? How long was the service unavailable? When was it restored, and how do you know? Each is a measurement before it is a sentence, and a regulator reading your final report a month later can line it up against your own status page. If the two disagree, that is a finding.

Perstat is built for the measurement. The incident’s start time is the moment a quorum of regions confirmed the failure, recorded to the second, not the first failed check and not a rounded minute. Detection and recovery times come out of the monitoring system as they happen, not from a recollection typed up afterward. The boundary you were alerted on is the boundary the SLA record uses later, so there is one clock, and it is not a human one.

Be exact about the line, because here it matters most: Perstat produces the availability evidence the framework keeps asking for. It is not the notification, the classification, or the legal judgment, and it does not make you DORA- or NIS2-ready. Those stay with you. For the mapping, field by field, see DORA incident reporting .

The number survives being recomputed

An availability number is worth something to a reviewer only if the service under test did not grade its own homework. Perstat measures from outside the service, from probes on six continents (na-ewr, eu-fra, as-sgp, sa-gru, af-jnb, oce-syd), and counts an incident only once a quorum of regions agrees. A single flaky route does not manufacture an outage, and one region’s good day does not hide a real one.

The same record feeds three views that usually drift apart: the public status page, the incident timeline, and the SLA record. Because they are one record, the story your customer sees and the story your auditor gets cannot quietly diverge. Curated exclusion windows carry their real boundaries: an announced maintenance window is excluded from the last good check before it to the first good check after, and an exclusion with no matching announced window is not accepted. Corrections are part of the record, not erasures. A discarded false positive carries a reason and the person who discarded it, its effect on uptime is previewed before it is applied, and it is reversible. Availability history is retained per plan, 7 days, 30, 90, 1 year, 2 years.

Here is the concrete shape, from the sample SLA report for a demo service over one quarter: 91 days, 131,040 minutes, 1,572,480 checks across six regions. One confirmed incident, a check failing at 02:40:42 from eu-fra, quorum confirmed at 02:41:12 when na-ewr and as-sgp agree, recovery confirmed across regions at 02:48:24. Gross availability 99.925%, and 99.994% after one curated, announced maintenance exclusion. Floored, never rounded up, because an SLA figure should be a lower bound you can defend. You can recompute every number, and the credibility of the result does not depend on any certificate status. The evidence pillar is the whole of it.

Incident timelines you did not assemble at 02:40

A final report wants root cause and a full timeline within a month, and the worst time to start building that is during the incident. In Perstat the timeline is already the record: raw status changes per region on one tab, curated outages on another, and a configuration audit, including “report discarded” and “report restored”, on a third. An acknowledgment is case ownership, recorded and cross-device, so who held the incident and when is on the record too.

On Sentinel and above, a post-mortem hangs off the incident it belongs to, with a template for impact, root cause, and lessons, moving from draft to published on your say-so. You choose whether it stays internal or goes public on a status page; nothing is published implicitly. When the one-month report is due, the timeline and the write-up are where you left them, attached to the incident, not scattered across a chat history.

Where the data sits, and who can reach it

Here provenance is examined, not assumed: customer and supervisory questionnaires ask where the data lives and who can compel it. Perstat is a German GmbH with no US parent. The control plane runs in the EU, GDPR applies with a DPA you can sign, and there is no US CLOUD Act reach because no US company sits in the chain. The probe nodes on six continents are measurement points; they hold no customer account data, and control and data stay in the EU.

That makes Perstat a clean line in your own DORA Article 28 register of ICT third parties. You add the entry; the GDPR pack that supports it, the DPA, the subprocessor list, and the technical and organizational measures, is available on request today. For context, with dates: DORA has applied since January 17, 2025, with its 4-hour, 72-hour, and one-month cascade; NIS2 pulls well over a hundred thousand companies across the EU into scope, an estimated 30,000 to 40,000 in Germany alone, of which about 39% were registered by the March 2026 deadline (BSI). Perstat is the independent availability evidence that feeds an ISAE 3402 or IDW PS 951 assurance report and a DORA incident notification. It is not that report.

Honest limits

• Perstat lists controls you can check and a founder who holds CISSP, CCSP, and ISSAP personally, rather than a wall of borrowed badges. See the security page .
• Perstat is a monitoring product, not a compliance consultancy. It produces availability evidence; it does not classify your incidents or write your filings.
• The record is recomputable, not tamper-proof. You can recompute the number; write-once, audit-proof archival is a roadmap note, not a current claim.
• A report export is the announced next step. Today the evidence is the curated record, its exclusions, the timeline, and the post-mortems; a PDF or CSV export of it is on request to hello@perstat.io for now.
• Enterprise SSO (SAML) is not available yet; sign-in is email-based today. Scope is deliberate: uptime and its evidence, not APM and not log management.

It holds up.

When the examiner asks how long you were down, the answer should already be measured, timestamped, and confirmed across regions, not assembled after the fact. That is the half of the problem Perstat solves, and it is the half a regulator checks first.

See a sample SLA report , read the security controls , or see how the record maps to DORA incident reporting .