En esta página
Son las 02:40 UTC. Uno de los 11 tipos de check regionales de Perstat informa de un fallo en tu API de pagos desde Fráncfort. Otras regiones incluidas en el plan dan el mismo resultado, y la política regional configurada confirma el incidente.
Esa confirmación crea un timestamp operativo. No clasifica el incidente según DORA. Si tu organización lo clasifica como incidente grave relacionado con las TIC, se aplican los plazos de notificación de DORA.
Lo difícil no es solo redactar los informes, sino reunir sus datos mientras corre el reloj. Un registro de monitorización puede aportar los tiempos de detección, confirmación y recuperación. Por sí solo no puede aportar la clasificación jurídica, el impacto en clientes o transacciones, la causa raíz ni la decisión de notificar.
En la parte de disponibilidad de ese trabajo importan tres puntos:
- qué puede aportar un registro de monitorización
- por qué las capturas y los hilos de Slack son débiles como única fuente
- dónde está el límite de Perstat
Esto no es asesoramiento jurídico, y la clasificación y la notificación siguen siendo responsabilidad tuya. Consulta las fuentes primarias: el Reglamento (UE) 2022/2554 y la norma técnica sobre el contenido y los plazos de notificación.
Tres plazos para los incidentes graves
DORA se aplica desde el 17 de enero de 2025. Para los incidentes graves relacionados con las TIC, el artículo 5 del Reglamento Delegado (UE) 2025/301 de la Comisión fija esta secuencia ordinaria:
| Informe | Plazo | Contenido |
|---|---|---|
| Notificación inicial | 4 horas desde su clasificación como grave | Campos iniciales que exige el formulario |
| Informe intermedio | 72 horas desde la notificación inicial | Hechos y estado actuales |
| Informe final | Un mes desde el último informe intermedio | Evaluación final y campos exigidos del formulario |
La notificación inicial se presenta lo antes posible. El plazo es de 4 horas desde que el incidente se clasifica como grave, y como máximo de 24 horas desde que se tiene conocimiento de él.
El informe intermedio se presenta como máximo 72 horas después de la notificación inicial. Actualízalo sin demora indebida cuando se recupere la actividad normal. El informe final vence como máximo un mes después del informe intermedio o del último informe intermedio actualizado.
El plazo de 4 horas empieza con la clasificación como grave, no con la caída. El límite separado de 24 horas corre desde que se tiene conocimiento del incidente. Mantén separados tres timestamps: la detección, el límite del incidente confirmado por la política y la clasificación.
La monitorización puede aportar los dos primeros según su política documentada. La clasificación es un juicio jurídico y operativo que queda fuera del producto de monitorización. El artículo 5 contiene otros casos particulares, así que manda el texto primario.
La monitorización ayuda en algunas preguntas del informe
La norma de notificación de la UE abarca mucho más que la disponibilidad. Un registro de monitorización puede contribuir a unas pocas preguntas directas:
- ¿Cuándo se detectó el incidente y cuándo empezó?
- ¿Cuánto tiempo estuvieron indisponibles los servicios?
- ¿Qué servicios monitorizados y regiones de sonda mostraron impacto?
- ¿Cuándo se restableció el servicio, y cómo lo sabes?
Por sí solo, el mismo registro no puede decir cuántos clientes o transacciones se vieron afectados. Tampoco puede, por sí mismo, cuantificar el impacto financiero o sobre los datos, establecer la extensión geográfica en sentido jurídico ni determinar la causa raíz. Incluso la caída medida depende del tipo de monitor documentado y de la política de incidentes.
Una página de estado puede añadir otra versión pública. Si su publicación o sus anotaciones difieren del registro interno, esa diferencia necesita una explicación. No des por hecho que la deriva sea imposible.
Capturas y chats son débiles como única fuente
Una captura de un panel y el historial de Slack pueden servir de punto de partida para reconstruir una caída a posteriori. Las dos cosas pueden aportar contexto. Ninguna es una fuente única sólida para los timestamps de monitorización.
Una captura suele mostrar un número en un momento concreto, no los eventos que hay detrás. También puede omitir el reloj, la política o la fuente.
Un hilo de chat recoge cuándo se habló del incidente, no necesariamente cuándo lo detectó o lo confirmó la monitorización. Los mensajes y los recuerdos siguen siendo útiles, pero hay que conciliarlos con el registro del sistema.
Un revisor puede preguntar con razón de dónde sale un timestamp, qué política lo produjo y si la curación posterior queda visible. Un registro continuo de eventos responde a esas preguntas de forma más directa que una imagen recortada o una secuencia recordada por sí solas.
Con límites comprobables, el registro se puede revisar
Un registro de disponibilidad puede contribuir al trabajo de notificación DORA si sus límites y la curación posterior se pueden inspeccionar. Esa contribución no equivale a un dictamen de compliance.
El sistema registra los timestamps
Los tiempos de detección y de recuperación salen de la propia monitorización. Se registran en el momento en que ocurren, no se teclean después. Un timestamp vale lo que vale el reloj que hay detrás.
La confirmación tiene un alcance explícito
Que falle una sola sonda regional puede significar que el objetivo está caído. También puede significar que una ruta de red está inestable. Para los 11 tipos de check regionales de Perstat, Free usa 2 regiones, Pulse 3, y Sentinel y los planes superiores hasta 6.
La política regional es configurable y usa de forma predeterminada un quórum de 2 regiones. En esos monitores, el inicio registrado del incidente es la confirmación de la política configurada, no la primera sonda fallida.
Los monitores agent y heartbeat no usan regiones ni quórum y siguen sus propias reglas de señal entrante. Es semántica del producto, no la definición jurídica de incidente de DORA.
Las exclusiones curadas siguen visibles
Perstat mantiene la caída medida separada del registro de indisponibilidad curado. Las ventanas de mantenimiento y de exclusión conservan sus límites reales. Una exclusión curada guarda el motivo y el autor y se puede revertir.
El objetivo es dejar visible la intervención, no maquillar el número. Ese registro del producto no hace que una exclusión sea aceptable automáticamente para una autoridad supervisora o una contraparte.
Las páginas de estado pueden compartir el registro
Un componente vinculado de la página de estado puede usar el mismo registro del monitor y del incidente. La publicación sigue siendo una acción explícita, y las anotaciones públicas pueden diferir del registro interno.
Una fuente compartida reduce la reconstrucción duplicada. No garantiza que todas las versiones públicas e internas sean idénticas.
Un ejemplo editorial muestra la aritmética
El informe SLA de ejemplo público de Perstat es una ilustración editorial y recalculable para un servicio de demostración. No es un informe generado para un cliente ni una exportación en autoservicio.
El ejemplo supone seis regiones durante un trimestre de 91 días, es decir, 131.040 minutos. En esas regiones cuenta 1.572.480 checks y un incidente confirmado:
- 02:40:42 UTC: un check falla desde eu (Fráncfort)
- 02:41:12 UTC: el quórum confirma cuando na (Newark) y as (Singapur) coinciden
- 02:48:24 UTC: la recuperación queda confirmada en todas las regiones
La ventana SLA va de la confirmación a la recuperación confirmada, de las 02:41:12 a las 02:48:24 UTC, y dura 7 minutos y 12 segundos. Los 30 segundos previos a la confirmación siguen visibles en el registro. No se estiran ni se encogen en silencio. El monitor de ejemplo aplica una política de 1 check fallido por región con un quórum de 2 regiones, no el valor predeterminado de 2 checks consecutivos.
La disponibilidad bruta es del 99,925 %, y del 99,994 % tras excluir la única ventana de mantenimiento anunciada. Puedes recalcular cada uno de esos números de ejemplo. Describen el ejemplo editorial, no el despliegue de un cliente.
Parte del informe y trabaja hacia atrás
Toma un campo del informe y pregúntate dónde vive su respuesta. Hazlo antes de un incidente, no después:
| Necesidad de notificación | Posible fuente en Perstat |
|---|---|
| Hora de detección | Timestamp de monitorización, registrado en directo |
| Hora de inicio del incidente | Confirmación por política configurada en sondas regionales |
| Duración de la indisponibilidad | Ventana entre confirmación y recuperación configuradas |
| Caída del servicio o de una ruta observada | Resultados de los 11 tipos de check regionales |
| Caída planificada o curación | Mantenimiento y exclusiones con límites, motivo y autor |
| Restablecimiento observado | Recuperación según la política configurada del monitor |
Los monitores agent y heartbeat siguen sus propias reglas de señal entrante, así que no los encajes a la fuerza en un modelo de quórum regional. Si hoy un campo necesario no tiene fuente, cierra esa brecha antes del siguiente evento notificable.
La monitorización cubre parte de la notificación DORA
Un producto de monitorización no te prepara para DORA. No clasifica ni presenta una notificación por ti. Esto sigue en tus manos:
- el alcance
- la clasificación
- el registro de terceros proveedores de TIC
- el flujo de notificación
- el juicio jurídico
La monitorización puede aportar estas partes al registro más amplio que reúne tu equipo:
- timestamps del sistema
- mediciones
- incidentes
- mantenimiento
- curación visible
Los 11 tipos de check regionales de Perstat incluyen HTTP, TCP y DNS. Según el plan, pueden bajar hasta intervalos de 10 segundos a través de MCP.
Estos tipos de check usan hasta seis regiones según el plan y la política regional configurada descrita arriba. Agent y heartbeat no usan ninguna de las dos cosas.
El control plane está en la UE, y la empresa que hay detrás es alemana. Estos hechos pueden respaldar un registro de disponibilidad, no una declaración de compliance con DORA.
Hoy el registro curado vive en el producto, y el ejemplo público es editorial. Cada vista de monitor ofrece un informe PDF de 7, 14, 30 o 90 días en todos los planes. El informe no está firmado ni certificado. Un CSV de la organización con manifiesto se facilita manualmente previa solicitud.
Revisa el tour del producto o el ejemplo editorial sin crear cuenta. Cuando quieras, empieza a monitorizar gratis.