Evidence behind DORA incident reporting deadlines

It is 02:40 UTC. One of Perstat’s 11 regional check types reports a failure against your payments API from Frankfurt. Further plan-selected regions report the same result, and the configured regional policy confirms the incident.

That confirmation creates an operational timestamp. It does not classify the incident under DORA. If your organization classifies it as a major ICT-related incident, DORA’s reporting deadlines apply.

The hard part is not only writing the reports but assembling their inputs while the clock runs. A monitoring record can contribute detection, confirmation, and recovery times. By itself, it cannot supply legal classification, customer or transaction impact, root cause, or the reporting decision.

For the availability part of that work, three points matter:

• what a monitoring record can contribute
• why screenshots and Slack threads are weak as sole sources
• where Perstat’s boundary sits

This is not legal advice, and classification and reporting stay your responsibility. Read the primary sources: Regulation (EU) 2022/2554 and the technical standard for notification content and time limits.

Three deadlines apply to major incidents

DORA has applied since 17 January 2025. For major ICT-related incidents, Article 5 of Commission Delegated Regulation (EU) 2025/301 sets this standard sequence:

Swipe sideways to inspect every column

The initial notification is due as early as possible. It is due within 4 hours of classifying the incident as major, and no later than 24 hours after awareness.

The intermediate report is due at the latest within 72 hours of submitting the initial notification. Update it without undue delay when regular activities recover. The final report is due no later than one month after the intermediate report or the latest updated intermediate report.

The 4-hour clock starts with classification as major, not when the outage starts. The separate 24-hour cap runs from awareness. Keep three timestamps separate: detection, the policy-confirmed incident boundary, and classification.

Monitoring can supply the first two under its documented policy. Classification is a legal and operational judgment outside the monitoring product. Article 5 contains further edge cases, so the primary text controls.

Monitoring can contribute to a few report questions

The EU reporting standard covers much more than availability. A monitoring record may contribute to a few direct questions:

• When was the incident detected, and when did it begin?
• How long were services unavailable?
• Which monitored services and probe regions showed an impact?
• When was service restored, and how do you know?

By itself, the same record cannot say how many clients or transactions were affected. Nor can it, on its own, quantify financial or data impact, establish legal geographic spread, or determine root cause. Even measured downtime depends on the documented monitor type and incident policy.

A status page can add another public account. If its publication or annotations differ from the internal record, that difference needs an explanation. Do not assume that drift is impossible.

Screenshots and chat logs are weak sole sources

A dashboard screenshot and a scroll back through Slack can be starting points for reconstructing an outage after the fact. Both can add context. Neither is a strong sole source for monitoring timestamps.

A screenshot usually shows a number at one captured moment, not the events behind it. It may also omit the clock, the policy, or the source.

A chat thread captures when people talked about the incident, not necessarily when monitoring detected or confirmed it. Messages and recollections can still be useful, but they need reconciliation with the system record.

A reviewer can reasonably ask where a timestamp came from, what policy produced it, and whether later curation is visible. A continuous event record answers those questions more directly than a cropped image or a remembered sequence alone.

Inspectable boundaries make a record reviewable

An availability record can contribute to DORA reporting work when its boundaries and later curation are inspectable. That contribution is not a compliance determination.

The system records the timestamps

Detection and recovery times come from the monitoring itself. They are recorded as they happen, not typed in afterward. A timestamp is only worth as much as the clock behind it.

Confirmation has an explicit scope

A single regional probe failure can mean the target is down. It can also mean that one network path is unstable. For Perstat’s 11 regional check types, Free uses 2 regions, Pulse 3, and Sentinel and above up to 6.

The regional policy is configurable and uses a quorum of 2 regions by default. For those monitors, the recorded incident start is the configured policy’s confirmation, not the first failed probe.

Agent and heartbeat monitors use neither regions nor quorum and follow their own incoming-signal rules. These are product semantics, not DORA’s legal definition of an incident.

Curated exclusions stay visible

Perstat keeps measured downtime separate from the curated outage record. Maintenance and exclusion windows keep their real boundaries. A curated exclusion retains its reason and actor and can be reversed.

The point is to make the intervention visible, not to flatter the number. That product record does not make an exclusion automatically acceptable to a regulator or counterparty.

Status pages can share the incident record

A linked status-page component can use the same monitor and incident record. Publishing remains an explicit action, and public annotations can differ from the internal record.

A shared source reduces duplicate reconstruction. It does not guarantee that every public and internal account is identical.

An editorial sample shows the arithmetic

Perstat’s public sample SLA report is an editorial, recomputable illustration for a demo service. It is not a generated customer report or a self-service export.

The sample assumes six regions over one quarter of 91 days, or 131,040 minutes. Across those regions, it counts 1,572,480 checks and one confirmed incident:

• 02:40:42 UTC: a check fails from eu (Frankfurt)
• 02:41:12 UTC: quorum confirms when na (Newark) and as (Singapore) agree
• 02:48:24 UTC: recovery is confirmed across regions

The SLA window runs from confirmation to confirmed recovery, 02:41:12 to 02:48:24 UTC, and lasts 7 minutes 12 seconds. The 30 seconds before confirmation stay visible in the record. They are not silently stretched or shrunk. The sample monitor runs a policy of 1 failed check per region with a quorum of 2 regions, not the default of 2 consecutive checks.

Gross availability is 99.925%, and 99.994% after excluding the one announced maintenance window. You can recompute every one of those sample numbers. They describe the editorial example, not a customer deployment.

Work backward from the report

Take a report field and ask where its answer lives. Do this before an incident, not after:

Agent and heartbeat monitors use their own incoming-signal rules, so do not force them into a regional-quorum model. If a required field has no source today, address that gap before the next reporting event.

Monitoring covers one part of DORA reporting

A monitoring product does not make you DORA-ready. It does not classify or file a report for you. These stay with you:

• scope
• classification
• the register of ICT third parties
• the reporting workflow
• legal judgment

Monitoring can contribute these parts to the wider record your team assembles:

• system timestamps
• measurements
• incidents
• maintenance
• visible curation

Perstat’s 11 regional check types include HTTP, TCP, and DNS. Depending on plan, they can run down to 10-second intervals through MCP.

These check types use up to six plan-dependent regions and the configured regional policy described above. Agent and heartbeat use neither.

The control plane is in the EU, and the company behind it is German. These facts can support an availability record, not a DORA compliance claim.

Today the curated record lives in the product, and the public sample is editorial. Each monitor view offers a PDF report for 7, 14, 30, or 90 days on every plan. The report is not signed or certified. An organization-level CSV plus manifest is available manually on request.

Review the product tour or the editorial sample without signing up. When you are ready, start monitoring free.