El panel verde, y el número que calla en voz baja

Lo que una página de estado puede decirte con honestidad, y lo que no

Todo proveedor de infraestructura tiene una página de estado, y la mayoría engaña en voz baja. Muestran un muro de verde y un número como 99,99%, y te invitan a concluir que el servicio es fiable. El número suele ser real. La conclusión a menudo no, porque en el correo concretamente se están midiendo dos cosas completamente distintas, y el panel verde solo cubre una. Esta página explica ambas, te dice a qué nos comprometemos de verdad, y te apunta a los datos en vivo en lugar de pedirte que confíes en una cifra de marketing.

Lo primero que se mide es la disponibilidad de la infraestructura: si los endpoints SMTP aceptan conexiones, si la API responde, si los paneles son accesibles. Eso es lo que una página de estado muestra bien, y es lo que reportamos. Lo segundo —lo que de verdad determina si tu correo cumple su función— es si los mensajes llegan a la bandeja de entrada. Ninguna página de estado de este sector lo muestra con honestidad, porque es más difícil de medir, varía según el dominio receptor, y mucho depende de factores que el proveedor no controla del todo. Preferimos ser claros con la distinción antes que dejar que un panel verde insinúe una promesa que no podemos cumplir.

El número de uptime, y cómo lo calculamos

Reportamos la disponibilidad sobre una ventana móvil de 90 días, no un reinicio mensual. Esto importa más de lo que suena. Una cifra mensual reinicia el contador el día uno de cada mes, lo que significa que un proveedor puede tener una semana genuinamente mala, esperar a que cambie el calendario, y mostrarte un 100% recién estrenado unos días después. La ventana móvil no deja esconderse así: un incidente grave permanece visible en el número durante un trimestre completo. Si estás evaluando fiabilidad, una cifra móvil de 90 días es la honesta para pedirle a cualquier proveedor, y la que debe darte mala espina cuando falta.

Los componentes que monitorizamos por separado son los que fallan de forma independiente: la ingesta del relay SMTP, la Email API, la entrega saliente desde los pools de IPs dedicadas, los servicios de DNS y autenticación, los paneles de cliente y el portal de facturación. Monitorizarlos por separado importa porque "el servicio" rara vez es todo-o-nada. La API puede estar degradada mientras SMTP va bien. La entrega saliente puede ralentizarse en un rango de IP mientras todo lo demás está sano. Un único número agregado esconde justo el detalle que un equipo de operaciones necesita durante un incidente, así que no lo agregamos hasta hacerlo desaparecer.

A qué nos comprometemos, expresado como objetivos y no como letra pequeña

Nuestro objetivo de disponibilidad para la ruta de envío principal —ingesta de relay SMTP y Email API— es del 99,95%. En una ventana de 90 días eso permite unas tres horas de indisponibilidad acumulada antes de incumplir el objetivo. Lo expresamos como objetivo en lugar de enterrar una garantía contractual en un acuerdo de servicio, y la distinción es deliberada. Un objetivo que publicamos y contra el cual reportamos con honestidad es más útil para la mayoría de clientes que una garantía cuyos términos de crédito reembolsan una fracción simbólica de la factura mensual. Los grandes proveedores cloud lo aprendieron por la vía cara: en un periodo reciente de doce meses, los tres mayores acumularon más de cien caídas de servicio entre ellos, todas nominalmente cubiertas por SLAs, con créditos que sumaban centavos frente al coste real de la caída para sus clientes.

Para clientes que necesitan un SLA contractual con créditos definidos —común en contratación regulada, y un requisito real bajo algunos marcos de proveedores del sector financiero— eso está disponible en los planes dedicados y Custom, redactado en el acuerdo con metodología de medición específica y tablas de crédito. El propósito del objetivo público es la transparencia para todos; el propósito del SLA contractual es el recurso para quienes sus obligaciones de cumplimiento lo exigen. Sirven a fines distintos y los mantenemos separados en lugar de fingir que el número público es un compromiso legal. Para clientes en España y Latinoamérica, donde la contratación pública (la del ENS español, por ejemplo) suele exigir compromisos de nivel de servicio explícitos, esa versión contractual es la que tu equipo de compras va a necesitar.

La parte que el panel verde no muestra: la colocación en bandeja

Aquí está la verdad incómoda que distingue al correo de casi cualquier otra infraestructura. Puedes tener 100% de uptime, el 100% de los mensajes aceptados y entregados al servidor receptor, y aun así tener una fracción significativa de ellos cayendo en spam. Entrega y colocación en bandeja son medidas distintas. Entrega significa que el servidor de correo receptor aceptó el mensaje. Colocación significa que llegó a la bandeja de entrada y no a la carpeta de no deseados. La brecha entre ambas es donde los programas de correo fracasan en silencio, y es invisible en una página de estado convencional.

Los benchmarks de 2026 hacen concreta la magnitud. La colocación mediana en bandeja entre sectores va desde alrededor del 86% en el extremo bajo hasta aproximadamente el 92% para remitentes B2B con programas disciplinados. Esos seis puntos de diferencia no son cuestión de uptime del servidor: todos los proveedores en esos datos tenían un uptime excelente. Es cuestión de reputación del remitente, postura de autenticación, higiene de listas y disciplina de envío. Un proveedor que te enseña 99,99% de disponibilidad y se calla sobre la colocación te está mostrando el número fácil y escondiendo el que determina si tus correos de facturación y tus restablecimientos de contraseña de verdad llegan.

No podemos poner la colocación en bandeja en un panel en tiempo real con honestidad, porque depende del dominio receptor, de tu comportamiento de envío, y de señales de reputación que se acumulan durante semanas. Lo que sí podemos hacer es ser transparentes en que es la métrica que importa, monitorizarla para clientes gestionados mediante pruebas con listas semilla y los informes DMARC agregados que procesamos, y tratar una caída de colocación como el incidente operativo que realmente es, en lugar de esperar a que el endpoint SMTP se ponga en rojo para actuar.

Cómo aparecen los incidentes aquí, y el lenguaje que usamos

Cuando algo sí va mal, el incidente recorre cuatro estados, y usamos el mismo vocabulario que el resto del sector ha adoptado para que no haya ambigüedad. Investigando significa que confirmamos un problema y lo estamos diagnosticando. Identificado significa que conocemos la causa y trabajamos en la solución. Monitorizando significa que la solución está desplegada y vigilamos que aguante. Resuelto significa que terminó y confiamos en que no recaerá de inmediato. Cada cambio de estado lleva una actualización con marca de tiempo, y mantenemos una cadencia fija de actualizaciones durante un incidente activo en lugar de quedarnos en silencio: el silencio entre actualizaciones erosiona la confianza más rápido que el propio incidente.

Los incidentes que tratamos como reportables van más allá del caso obvio del endpoint caído. Un evento de blocklist en un rango compartido, una ralentización sostenida de la entrega, un problema de DNS o autenticación que afecta a un subconjunto de clientes, una caída del panel: todos se publican, porque desde el lado del cliente una ralentización de entrega que no puede explicarse es tan alarmante como una caída dura. Para incidentes que tocan datos personales, la línea de tiempo del estado corre en paralelo con el proceso formal de notificación de brechas descrito en el Acuerdo de Procesamiento de Datos, que lleva el reloj reglamentario de 72 horas bajo el RGPD.

Los incidentes pasados permanecen visibles

El historial de incidentes no se poda en silencio una vez resueltas las cosas. Los incidentes pasados permanecen en la línea de tiempo con su rastro completo de actualizaciones y, donde es útil, una breve nota post-incidente sobre qué lo causó y qué cambió después. Esto es en parte rendición de cuentas y en parte algo más práctico: el historial de incidentes de un proveedor es una de las pocas señales honestas que tienes sobre cómo opera de verdad. Una página que muestra un puñado de incidentes a lo largo de años, cada uno resuelto rápido con una explicación clara, te dice más sobre fiabilidad que cualquier porcentaje de uptime. Una página sin historial alguno suele significar que la página es nueva, no que el proveedor sea infalible.

El mantenimiento, y por qué lo programamos como lo hacemos

El mantenimiento planificado se anuncia con antelación en el panel de estado, se programa en las ventanas de menor tráfico para las regiones afectadas, y se estructura para que la ruta de envío siga disponible incluso mientras se trabaja en un panel o un servicio secundario. La infraestructura de correo tiene aquí una propiedad útil: el correo saliente puede encolarse. Una ventana breve de mantenimiento en un componente no crítico rara vez significa correo perdido, porque la cola lo absorbe y la entrega se reanuda cuando el componente vuelve. Aun así lo anunciamos, porque un cliente que vigila sus propios paneles merece saber por qué se movió un número, incluso cuando en realidad nada estuvo en riesgo.

Qué es esta página, en una frase honesta

Es una descripción de la disponibilidad de la infraestructura que reportamos con transparencia sobre una ventana móvil, emparejada con la admisión abierta de que la métrica que la mayoría de proveedores esconde —si tu correo llega a la bandeja— es la que de verdad importa, y la que preferimos hablar contigo directamente antes que reducir a un punto verde engañoso. La fiabilidad en este negocio no es un número en un panel. Son 23 años del mismo equipo manteniendo la cola en movimiento, y un historial de incidentes lo bastante corto como para leerlo en unos minutos.