Auf dieser Seite
Es ist 02:40 UTC. Einer der 11 regionalen Checktypen von Perstat meldet aus Frankfurt einen Fehler für Ihre Payments-API. Weitere im Tarif gewählte Regionen melden dasselbe Ergebnis, und die konfigurierte regionale Richtlinie bestätigt den Incident.
Diese Bestätigung erzeugt einen betrieblichen Zeitstempel. Sie stuft den Vorfall nicht nach DORA ein. Stuft Ihre Organisation ihn als schwerwiegenden IKT-bezogenen Vorfall ein, gelten die Meldefristen von DORA.
Schwierig ist nicht nur, die Meldungen zu schreiben, sondern ihre Eingangsdaten zusammenzutragen, während die Uhr läuft. Eine Monitoring-Aufzeichnung kann die Zeitpunkte von Erkennung, Bestätigung und Wiederherstellung beitragen. Allein liefert sie keine rechtliche Einstufung, keine Angaben zur Auswirkung auf Kunden oder Transaktionen, keine Ursache und keine Meldeentscheidung.
Für den Verfügbarkeitsteil dieser Arbeit zählen drei Punkte:
- was eine Monitoring-Aufzeichnung beitragen kann
- warum Screenshots und Slack-Verläufe als alleinige Quelle schwach sind
- wo die Grenze von Perstat liegt
Das ist keine Rechtsberatung. Einstufung und Meldung bleiben in Ihrer Verantwortung. Lesen Sie die Primärquellen: die Verordnung (EU) 2022/2554 und den technischen Standard zu Inhalt und Fristen der Meldungen.
Für schwerwiegende Vorfälle gelten drei Fristen
DORA gilt seit dem 17. Januar 2025. Für schwerwiegende IKT-bezogene Vorfälle legt Artikel 5 der Delegierten Verordnung (EU) 2025/301 diese reguläre Abfolge fest:
| Meldung | Frist | Inhalt |
|---|---|---|
| Erstmeldung | Spätestens 4 Stunden nach Einstufung als schwerwiegend | Erste Angaben laut Meldeformular |
| Zwischenbericht | Spätestens 72 Stunden nach der Erstmeldung | Aktueller Sachstand und Status |
| Abschlussbericht | Spätestens einen Monat nach dem letzten Zwischenbericht | Abschließende Bewertung und Pflichtfelder des Formulars |
Die Erstmeldung ist so früh wie möglich fällig. Sie muss innerhalb von 4 Stunden nach der Einstufung als schwerwiegend abgegeben sein, spätestens aber 24 Stunden nach Kenntnis des Vorfalls.
Der Zwischenbericht ist spätestens 72 Stunden nach Abgabe der Erstmeldung fällig. Aktualisieren Sie ihn unverzüglich, sobald der reguläre Betrieb wiederhergestellt ist. Der Abschlussbericht ist spätestens einen Monat nach dem Zwischenbericht oder dem letzten aktualisierten Zwischenbericht fällig.
Die 4-Stunden-Frist beginnt mit der Einstufung als schwerwiegend, nicht mit dem Ausfall. Die separate 24-Stunden-Obergrenze läuft ab Kenntnis des Vorfalls. Halten Sie drei Zeitstempel getrennt: die Erkennung, die per Richtlinie bestätigte Incident-Grenze und die Einstufung.
Das Monitoring kann die ersten beiden nach seiner dokumentierten Richtlinie liefern. Die Einstufung ist eine rechtliche und betriebliche Entscheidung außerhalb des Monitoring-Produkts. Artikel 5 enthält weitere Sonderfälle, deshalb ist der Primärtext maßgeblich.
Monitoring trägt zu einigen Meldefragen bei
Der EU-Meldestandard umfasst weit mehr als Verfügbarkeit. Eine Monitoring-Aufzeichnung kann zu einigen direkten Fragen beitragen:
- Wann wurde der Incident erkannt, und wann hat er begonnen?
- Wie lange waren Dienste nicht verfügbar?
- Welche überwachten Dienste und Prüfregionen zeigten eine Beeinträchtigung?
- Wann war der Dienst wiederhergestellt, und woher wissen Sie das?
Allein kann dieselbe Aufzeichnung nicht sagen, wie viele Kunden oder Transaktionen betroffen waren. Ebenso wenig kann sie für sich genommen den finanziellen oder datenbezogenen Schaden beziffern, die rechtlich relevante geografische Ausbreitung feststellen oder die Ursache bestimmen. Selbst die gemessene Ausfallzeit hängt vom dokumentierten Monitortyp und von der Incident-Richtlinie ab.
Eine Statusseite kann eine weitere öffentliche Darstellung beisteuern. Weichen ihre Veröffentlichung oder ihre Anmerkungen von der internen Aufzeichnung ab, braucht dieser Unterschied eine Erklärung. Gehen Sie nicht davon aus, dass Abweichungen unmöglich sind.
Screenshots und Chatverläufe allein sind schwache Quellen
Ein Dashboard-Screenshot und ein zurückgescrollter Slack-Verlauf können Ausgangspunkte sein, um einen Ausfall nachträglich zu rekonstruieren. Beides kann Kontext liefern. Keines von beiden ist eine starke alleinige Quelle für Monitoring-Zeitstempel.
Ein Screenshot zeigt meist eine Zahl zu einem einzigen Aufnahmezeitpunkt, nicht die Ereignisse dahinter. Zudem kann er Uhr, Richtlinie oder Quelle auslassen.
Ein Chatverlauf hält fest, wann Menschen über den Incident gesprochen haben, nicht zwingend, wann das Monitoring ihn erkannt oder bestätigt hat. Nachrichten und Erinnerungen bleiben nützlich, müssen aber mit der Systemaufzeichnung abgeglichen werden.
Wer die Meldung prüft, kann zu Recht fragen, woher ein Zeitstempel stammt, welche Richtlinie ihn erzeugt hat und ob spätere Kuration sichtbar ist. Eine fortlaufende Ereignisaufzeichnung beantwortet diese Fragen direkter als ein zugeschnittenes Bild oder eine erinnerte Reihenfolge allein.
Einsehbare Grenzen machen eine Aufzeichnung prüfbar
Eine Verfügbarkeitsaufzeichnung kann zur Arbeit an DORA-Meldungen beitragen, wenn ihre Grenzen und die spätere Kuration einsehbar sind. Dieser Beitrag ist keine Compliance-Feststellung.
Das System zeichnet die Zeitstempel auf
Erkennungs- und Wiederherstellungszeiten stammen aus dem Monitoring selbst. Sie werden aufgezeichnet, wenn sie eintreten, und nicht nachträglich eingetippt. Ein Zeitstempel ist nur so viel wert wie die Uhr dahinter.
Die Bestätigung hat einen klaren Geltungsbereich
Meldet ein einzelner regionaler Prüfpunkt einen Fehler, kann das Ziel ausgefallen sein. Es kann aber auch nur ein Netzpfad instabil sein. Für die 11 regionalen Checktypen von Perstat nutzt Free 2 Regionen, Pulse 3 und ab Sentinel bis zu 6.
Die regionale Richtlinie ist konfigurierbar und nutzt standardmäßig ein Quorum von 2 Regionen. Bei diesen Monitoren ist der aufgezeichnete Incident-Beginn die Bestätigung durch die konfigurierte Richtlinie, nicht der erste Fehler eines Prüfpunkts.
Agent- und Heartbeat-Monitore nutzen weder Regionen noch Quorum und folgen eigenen Regeln für eingehende Signale. Das ist Produktsemantik, nicht die rechtliche Incident-Definition von DORA.
Kuratierte Ausschlüsse bleiben sichtbar
Perstat hält die gemessene Ausfallzeit getrennt von der kuratierten Ausfallaufzeichnung. Wartungs- und Ausschlussfenster behalten ihre echten Grenzen. Ein kuratierter Ausschluss bewahrt Grund und Urheber und lässt sich zurücknehmen.
Es geht darum, den Eingriff sichtbar zu machen, nicht die Zahl zu schönen. Diese Aufzeichnung im Produkt macht einen Ausschluss nicht automatisch für eine Aufsicht oder einen Vertragspartner akzeptabel.
Statusseiten können die Incident-Aufzeichnung teilen
Eine verknüpfte Statusseiten-Komponente kann dieselbe Monitor- und Incident-Aufzeichnung nutzen. Die Veröffentlichung bleibt ein ausdrücklicher Schritt, und öffentliche Anmerkungen können von der internen Aufzeichnung abweichen.
Eine gemeinsame Quelle verringert doppelte Rekonstruktionsarbeit. Sie garantiert nicht, dass jede öffentliche und interne Darstellung identisch ist.
Ein redaktionelles Beispiel zeigt die Rechnung
Der öffentliche Beispiel-SLA-Report von Perstat ist ein redaktionelles, nachrechenbares Beispiel für einen Demo-Dienst. Er ist kein erzeugter Kundenreport und kein Self-Service-Export.
Das Beispiel nimmt sechs Regionen über ein Quartal von 91 Tagen an, also 131.040 Minuten. Über diese Regionen zählt es 1.572.480 Checks und einen bestätigten Incident:
- 02:40:42 UTC: Check aus eu (Frankfurt) schlägt fehl
- 02:41:12 UTC: Quorum bestätigt, weil na (Newark) und as (Singapur) zustimmen
- 02:48:24 UTC: Wiederherstellung über alle Regionen bestätigt
Das SLA-Fenster reicht von der Bestätigung bis zur bestätigten Wiederherstellung, also von 02:41:12 bis 02:48:24 UTC, und dauert 7 Minuten 12 Sekunden. Die 30 Sekunden vor der Bestätigung bleiben in der Aufzeichnung sichtbar. Sie werden nicht stillschweigend gedehnt oder gekürzt. Der Beispiel-Monitor nutzt eine Regel von 1 fehlgeschlagenen Check je Region mit einem Quorum von 2 Regionen, nicht die Voreinstellung von 2 aufeinanderfolgenden Checks.
Die Bruttoverfügbarkeit liegt bei 99,925 %, nach Ausschluss des einen angekündigten Wartungsfensters bei 99,994 %. Jede dieser Beispielzahlen können Sie nachrechnen. Sie beschreiben das redaktionelle Beispiel, keinen Kundeneinsatz.
Von der Meldung aus rückwärts planen
Nehmen Sie ein Feld der Meldung und fragen Sie, wo die Antwort darauf liegt. Tun Sie das vor einem Incident, nicht danach:
| Benötigte Angabe | Mögliche Perstat-Quelle |
|---|---|
| Zeitpunkt der Erkennung | Monitoring-Zeitstempel, live aufgezeichnet |
| Beginn des Incidents | Bestätigung per konfigurierter Richtlinie bei regionalen Prüfpunkten |
| Dauer der Nichtverfügbarkeit | Fenster von konfigurierter Bestätigung bis konfigurierter Wiederherstellung |
| Dienstausfall oder nur eine beobachtete Route | Regionale Ergebnisse der 11 regionalen Checktypen |
| Geplante Ausfallzeit oder Kuration | Wartung und Ausschlüsse mit Grenzen, Grund und Urheber |
| Beobachtete Wiederherstellung | Wiederherstellung nach der konfigurierten Richtlinie des Monitors |
Agent- und Heartbeat-Monitore folgen eigenen Regeln für eingehende Signale. Pressen Sie sie deshalb nicht in ein Modell mit regionalem Quorum. Fehlt für ein benötigtes Feld heute eine Quelle, schließen Sie diese Lücke vor dem nächsten Meldefall.
Monitoring deckt einen Teil der DORA-Meldung ab
Mit einem Monitoring-Produkt allein sind Sie nicht auf DORA vorbereitet. Es stuft keinen Vorfall für Sie ein und reicht keine Meldung ein. Diese Punkte bleiben bei Ihnen:
- Geltungsbereich
- Einstufung
- Informationsregister zu IKT-Drittdienstleistern
- Meldeprozess
- rechtliche Bewertung
Das Monitoring kann diese Teile zu der größeren Aufzeichnung beitragen, die Ihr Team zusammenstellt:
- Systemzeitstempel
- Messungen
- Incidents
- Wartung
- sichtbare Kuration
Die 11 regionalen Checktypen von Perstat umfassen HTTP, TCP und DNS. Je nach Tarif können sie über MCP in Intervallen bis hinunter zu 10 Sekunden laufen.
Diese Checktypen nutzen bis zu sechs tarifabhängige Regionen und die oben beschriebene konfigurierte regionale Richtlinie. Agent und Heartbeat nutzen keines von beiden.
Die Control Plane liegt in der EU, und das Unternehmen dahinter ist deutsch. Diese Fakten können eine Verfügbarkeitsaufzeichnung stützen, keine Aussage zur DORA-Compliance.
Heute liegt die kuratierte Aufzeichnung im Produkt, und das öffentliche Beispiel ist redaktionell. Jede Monitoransicht bietet einen PDF-Report für 7, 14, 30 oder 90 Tage, in jedem Tarif. Der Report ist weder signiert noch beglaubigt. Eine CSV-Datei auf Organisationsebene samt Manifest erhalten Sie manuell auf Anfrage.
Sehen Sie sich die Produkttour oder das redaktionelle Beispiel ohne Anmeldung an. Wenn Sie so weit sind, starten Sie das Monitoring kostenlos.