Comunicar una caída sin alarmar de más

Una fuente oficial deja de responder a media mañana. La integración devuelve errores, el panel muestra consultas incompletas y alguien tiene que escribir el aviso. Ese texto lo va a leer gente que no vio ningún gráfico interno y que, con lo que diga, decide si sigue operando o si frena.

Hay dos maneras de equivocarse y son simétricas. Un aviso demasiado suave —“estamos experimentando intermitencias”— deja que el lector interprete el silencio como normalidad y tome un resultado vacío por una respuesta buena. Un aviso demasiado dramático convierte la falla de una jurisdicción en la impresión de que nada funciona, y frena entregas, altas y liberaciones que nunca estuvieron afectadas.

El aviso calibrado no es un punto medio de tono. Es un texto que dice exactamente qué dejó de funcionar, qué se ve desde afuera y qué conclusión no se puede sacar mientras dure.

Alcance primero, causa después

Lo primero que necesita el lector es un recorte. Qué superficie está afectada —consultas nuevas, historial, notificaciones, descargas—, qué fuentes o jurisdicciones y desde qué hora. Con eso cada equipo sabe si el problema lo toca.

La causa técnica, en cambio, suele ser una hipótesis durante las primeras horas: publicarla temprano y corregirla después desgasta más confianza que el corte mismo. Conviene reservarla para cuando esté confirmada y decir mientras tanto que se está investigando.

También ayuda nombrar lo que sí funciona: enumerar las superficies no afectadas evita que el lector generalice por precaución.

Contar el efecto observable, no la arquitectura

A quien integra no le sirve saber qué componente falló: le sirve saber qué va a ver. Si las consultas devuelven un error temporal, decilo con esas palabras. Si devuelven resultados parciales, decí que están incompletos y en qué campo se marca esa condición.

Del lado automático, la semántica HTTP ya prevé el caso: una respuesta de indisponibilidad temporal puede acompañarse de un encabezado que sugiere cuándo reintentar. Eso ordena a los clientes, pero no reemplaza el aviso a las personas, que además necesitan saber qué hacer con lo que ya recibieron.

El texto legible que viaja dentro de un error estructurado da un criterio útil para todo el aviso: está pensado para que quien integra pueda corregir o esperar, no para darle detalle de depuración. Nombres de host, rutas internas y volcados del proveedor no ayudan a nadie y agrandan la superficie expuesta.

La frase que no puede faltar

Hay una línea que un aviso de este rubro no debería omitir: una consulta que falló no es una consulta sin infracciones. Es la conclusión equivocada más cara y la más fácil de sacar: un resultado vacío se parece bastante a una buena noticia.

Escrita de forma explícita, esa frase le avisa a quien está por liberar un vehículo o firmar una entrega que ese chequeo no cuenta y hay que repetirlo. Sin ella el aviso informa en lo técnico y no evita nada en lo operativo. Cómo se representa ese hueco en la respuesta está en qué devolver cuando una jurisdicción falla.

Comprometer la próxima actualización, no la solución

La pregunta que todos hacen es cuándo se arregla, y es la que menos se puede responder al principio. Prometer una hora y no cumplirla obliga a un segundo aviso que nace con menos crédito.

Lo que sí se puede comprometer es la hora del próximo mensaje, y sostenerla aunque no haya novedades: “seguimos sin restablecer la fuente, próximo aviso a las trece” también es información. Una cadencia previsible vuelve innecesario que el cliente pregunte.

Conviene no confundir esa hora con los objetivos de recuperación. Un objetivo de tiempo de recuperación describe cuánta interrupción se considera aceptable; uno de punto de recuperación, cuánta pérdida de datos. Se acuerdan al planificar la continuidad y sirven para diseñar y probar, no para pronosticar cuánto durará el incidente en curso.

Plantilla, canales y cierre

Improvisar el texto mientras se apaga el incendio produce avisos desparejos. Las guías de planificación de contingencias tratan la notificación como un procedimiento escrito, con roles y destinatarios definidos de antemano.

En la práctica alcanza con poco: una plantilla de campos fijos —alcance, efecto observable, lo que no se puede concluir, hora del próximo aviso—, una lista de canales por audiencia y un responsable de publicar. El panel de estado, el correo a las flotas y el mensaje dentro del producto pueden tener distinto detalle, pero no contradecirse.

El mensaje de cierre tampoco es un “ya está”. Dice desde qué hora el servicio responde con normalidad, qué consultas del período afectado conviene repetir y si quedaron resultados marcados como incompletos.

Antes de publicar cualquiera de estos textos, verificá tres cosas: que el alcance declarado coincida con lo que muestran las mediciones, que la frase sobre resultados vacíos esté presente y que la hora anunciada sea una que se va a cumplir. Un aviso que pasa esas tres revisiones informa sin asustar y, sobre todo, sin tranquilizar de más.

Metodología

Alcance

Criterios de redacción y cadencia para el aviso de una interrupción total o parcial en una integración de consultas de infracciones. No cubre el diseño del contrato de la API ni el análisis posterior de causa raíz.

Unidad de análisis

Un aviso publicado durante un incidente: el alcance que declara, el efecto observable que describe y la hora del mensaje siguiente.

Cobertura

Semántica HTTP de respuestas temporales y de errores estructurados, junto con prácticas generales de planificación de contingencias y objetivos de recuperación, revisadas al 29 de agosto de 2026.

Limitaciones

• No reemplaza los compromisos contractuales de nivel de servicio ni fija plazos de notificación exigibles a un proveedor determinado.
• Las plantillas se adaptan al canal: un panel de estado, un correo a la flota y una respuesta de API admiten distinto nivel de detalle.
• La nota trata el texto del aviso; la detección, la mitigación y el análisis posterior del incidente tienen procesos propios.

Fuentes

• RFC 9110 — HTTP Semantics — RFC Editor (consultada el 2026-08-29)
• RFC 9457 — Problem Details for HTTP APIs — RFC Editor (consultada el 2026-08-29)
• SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — National Institute of Standards and Technology (consultada el 2026-08-29)
• Recovery objectives RTO and RPO — Amazon Web Services (consultada el 2026-08-29)

Preguntas frecuentes

¿Conviene explicar la causa técnica en el primer aviso?

Rara vez. Durante las primeras horas la causa suele ser una hipótesis, y corregirla después desgasta más confianza que el corte mismo. El primer mensaje puede limitarse al alcance, al efecto observable y a la hora del siguiente aviso; la causa entra cuando está confirmada.

¿Hay que anunciar una hora estimada de solución?

Es preferible comprometer la hora de la próxima actualización. Los objetivos de recuperación describen cuánta interrupción y cuánta pérdida de datos se consideran aceptables al planificar la continuidad del servicio: son metas de diseño y prueba, no un pronóstico de cuánto va a durar este incidente.

¿Una respuesta de indisponibilidad temporal alcanza como aviso?

No. La semántica HTTP prevé señalar una condición temporal y sugerir cuándo reintentar, lo cual orienta a los clientes automáticos. Las personas que operan una flota necesitan además saber qué consultas quedaron sin cobertura y cuáles conviene repetir después.

¿Qué no debería incluir el mensaje de error que ve el cliente?

El formato de errores estructurados prevé un texto legible orientado a que quien integra pueda corregir o esperar, no a dar detalle de depuración. Rutas internas, nombres de host, volcados del proveedor y credenciales no le sirven a quien recibe el aviso y amplían la superficie expuesta.

Notas relacionadas