DANAconnect incident

Experiencing delays in message processing

Minor Resolved View vendor source →

DANAconnect experienced a minor incident on September 30, 2026 affecting Email platform and Director - Workflow Orchestration and 1 more component, lasting 1h 21m. The incident has been resolved; the full update timeline is below.

Started
Sep 30, 2026, 05:21 PM UTC
Resolved
Sep 30, 2026, 06:42 PM UTC
Duration
1h 21m
Detected by Pingoru
Sep 30, 2026, 05:21 PM UTC

Affected components

Email platformDirector - Workflow OrchestrationWebhooks (API Request Node)One Time Password APIConversation API

Update timeline

  1. investigating Sep 30, 2026, 05:21 PM UTC

    We are currently experiencing delays in shipping processing and dispatch due to a high volume of traffic on our services. Our team is actively working to resolve the issue and restore normal operations as quickly as possible.

  2. identified Sep 30, 2026, 06:03 PM UTC

    We are pleased to inform you that our shipping and dispatch processing services have stabilized and returned to normal operations. Our team continues to actively monitor the situation to ensure seamless performance

  3. monitoring Sep 30, 2026, 06:03 PM UTC

    A fix has been implemented and we are monitoring the results.

  4. resolved Sep 30, 2026, 06:42 PM UTC

    Procesamiento de Envíos y Despachos Servicio afectado: Proceso de Envíos y Despacho (Shipping & Dispatch Processing Services) Estado: Resuelto / Estabilizado 1. Resumen Los servicios de procesamiento de envíos y despachos experimentaron una degradación de rendimiento y retrasos operativos debido a un alto volumen de transacciones de actualización sobre la base de datos. El incidente comenzó a manifestar un incremento sostenido de latencia y procesamiento alrededor de las 12:21 EDT, alcanzando un pico crítico inicial entre las 12:22 y las 12:24 EDT, y manteniendo un nivel elevado de carga y saturación constante desde las 12:38 EDT hasta las 13:38 EDT. Tras la aplicación de una corrección de emergencia en la lógica de actualización, el servicio retornó a parámetros normales operacionales a las 13:43 EDT, confirmándose la resolución y estabilización definitiva a las 14:03 EDT. 2. Cronología del Incidente (Timeline) 12:15 EDT - 12:20 EDT: Inicio del incremento gradual en las solicitudes de procesamiento. 12:21 EDT: Caída momentánea seguida de un pico pronunciado de solicitudes/latencia a las 12:22 - 12:24 EDT. 12:25 EDT - 12:35 EDT: Fluctuación del volumen por encima del umbral promedio normal (línea punteada). 12:38 EDT: Comienza el periodo sostenido de alta saturación del servicio debido a la contención en la base de datos. 13:00 EDT - 13:30 EDT: Mantenimiento prolongado del pico de saturación al límite operacional del sistema. 13:38 EDT: Despliegue de la solución y comienzo del descenso progresivo de la carga acumulada. 13:40 EDT: Caída drástica del encolamiento tras la ejecución del nuevo proceso unificado de actualización. 13:43 EDT: Las métricas de rendimiento y tiempos de respuesta vuelven a los niveles baseline normales. 14:03 EDT: Publicación oficial de la resolución del incidente tras verificar la estabilidad continua del sistema ("Identified - Services stabilized and returned to normal operations"). 3. Análisis de Impacto Duración total del incidente: ~1 hora y 22 minutos (degradación registrada desde las 12:21 hasta las 13:43 EDT). Duración de la degradación crítica: ~1 hora (12:38 EDT – 13:38 EDT). Servicios afectados: Módulo de procesamiento de envíos,y cola de peticiones asociadas. 4. Causa Raíz El incidente fue provocado por un elevado incremento en el volumen de actualizaciones (updates) sobre la tabla de despachos de la base de datos. La arquitectura ejecutaba estas actualizaciones de forma escalonada por bloques mediante múltiples procesos individuales y simultáneos. Al aumentar la carga, la ejecución concurrente sobre la misma tabla generó un bloqueo de recursos (table/row locking) y una alta contención en la base de datos, derivando en un cuello de botella que saturó el procesamiento de envíos entre las 12:38 EDT y las 13:38 EDT. 5. Acciones de Mitigación y Resolución Corrección de Emergencia (Hotfix): El equipo DevOps implementó un ajuste de emergencia para consolidar y aplicar las actualizaciones de manera masiva a través de un único proceso optimizado, eliminando la contención por múltiples procesos en paralelo. Descongestión del Sistema: Al reducirse los bloqueos en la tabla, el backlog acumulado se procesó rápidamente. La carga cayó drásticamente a las 13:40 EDT, logrando la estabilización completa del servicio a las 13:43 EDT y la confirmación final de normalidad a las 14:03 EDT.