Un timeout no siempre dice qué ocurrió con una operación. Dice algo más limitado: que nuestro sistema dejó de recibir una respuesta dentro del intervalo esperado. Entre una cosa y la otra hay una diferencia enorme, sobre todo cuando participan varias jurisdicciones, proveedores y relojes.
En ese momento no necesito una explicación brillante. Necesito que otra persona pueda abrir el caso dentro de una hora —o al día siguiente— y entender qué se intentó, qué se confirmó y qué sigue sin saberse.
Primero: separar el hecho de la interpretación
El hecho es “no recibimos respuesta a tiempo”. “La operación falló”, “el banco la rechazó” o “el destinatario ya la tiene” son interpretaciones que necesitan evidencia. Si las mezclamos en el mismo campo, el siguiente operador hereda una conclusión difícil de deshacer.
Por eso registraría dos cosas distintas: el último evento observado y la hipótesis operativa que se está investigando. La primera puede cerrar una auditoría; la segunda debe poder cambiar sin reescribir la historia.
La ficha mínima del timeout
La ficha no debe ser un volcado de logs ni un relato interminable. Debe ser pequeña, estable y suficiente para correlacionar sistemas:
- Identidad: identificador interno, referencia de correlación y, si existe, referencia del proveedor. Nunca hace falta mostrar secretos para que el caso sea rastreable.
- Intención: acción solicitada, moneda e importe con la precisión original, sin convertir la ficha en un documento comercial.
- Línea de tiempo: hora de inicio, último evento, momento del timeout y zona horaria. Guardar los timestamps tal como llegaron y normalizarlos sólo para compararlos.
- Estado confirmado: la última respuesta verificable y quién o qué sistema la confirmó.
- Estado pendiente: la pregunta concreta que queda abierta, por ejemplo si el proveedor aceptó la instrucción o si existe una confirmación posterior.
- Control de repetición: referencia de idempotencia o mecanismo equivalente, con acceso restringido cuando su valor sea sensible.
- Propiedad: responsable actual, siguiente acción y hora límite para actualizar el caso.
La última línea es la que más se olvida. Un registro sin dueño es sólo una nota; no es una excepción operable.
Una línea de tiempo que alguien pueda leer
En lugar de sustituir una entrada cada vez que cambia el estado, conservaría eventos breves y ordenados. Un formato sencillo puede ser:
14:02:11Z · solicitud creada · sistema interno14:02:14Z · referencia aceptada · proveedor14:07:14Z · timeout de respuesta · sistema interno14:12:00Z · consulta de estado abierta · responsable de operaciones
Es un ejemplo de forma, no un registro real. Lo importante es que cada línea responda a tres preguntas: cuándo ocurrió, qué se observó y de qué fuente proviene. Si una fuente corrige un estado anterior, se añade un evento; no se borra silenciosamente el anterior.
Qué hacer con los reintentos
Después de un timeout, el botón “reintentar” puede ser una decisión operativa, no una función inocente de interfaz. Antes de repetir, comprobaría si la primera intención tiene una clave idempotente, si el proveedor permite consultar su estado y si existe una cola para los casos que no pueden resolverse todavía.
Si no puedo demostrar que la primera operación no fue aceptada, no la duplico para tranquilizar la pantalla. Marco la incertidumbre, consulto la fuente adecuada y dejo visible quién hará la siguiente comprobación.
La comunicación también forma parte del registro
La actualización externa debería salir de la misma ficha: último hecho confirmado, incertidumbre concreta y próximo momento de información. No hace falta inventar una causa ni prometer un plazo que depende de otra organización. Sí hace falta que el destinatario sepa si está ante una espera, una devolución, una investigación o un estado todavía desconocido.
Cuando una hipótesis cambia, se registra el cambio y la evidencia que lo provocó. Así el equipo no discute después qué versión “se dijo”, sino qué se sabía en cada momento.
Privacidad: registrar lo necesario, no todo lo accesible
Un buen runbook no es una excusa para copiar datos sensibles. Enmascararía cuentas y destinos, limitaría el acceso a referencias que permitan identificar a una persona y mantendría los secretos fuera de los mensajes de soporte. La retención y el acceso deben seguir la política aplicable a la entidad y a la jurisdicción; este artículo no la sustituye.
La prueba útil es sencilla: ¿puede una persona autorizada continuar la investigación sin que el registro revele más información de la necesaria? Si la respuesta es no, hay que rediseñar la ficha, no pedir más datos.
Cerrar sólo cuando la evidencia cierra
Un timeout deja de ser una excepción abierta cuando una fuente autorizada confirma un resultado —completado, devuelto, rechazado o cancelado— y el estado interno refleja esa conclusión. Hasta entonces, “sin novedades” no es lo mismo que “resuelto”.
Esta disciplina tiene un efecto menos visible: permite que producto, operaciones y cumplimiento hablen de la misma operación sin convertir una pantalla sencilla en una caja negra.
Nota: contenido informativo basado en experiencia de producto. No constituye asesoramiento legal, regulatorio, fiscal o financiero ni una oferta de servicios. Las obligaciones concretas dependen de la entidad, el proveedor y la jurisdicción aplicables.
Fuentes y límites
- BIS · CPMI — trabajo sobre pagos transfronterizos y sus fricciones operativas.
- ISO 20022 — mensajería financiera y referencias estructuradas.
- NIST Privacy Framework — enfoque de gestión de riesgos de privacidad.
Alex Sicart Ramos escribe sobre infraestructura, operaciones y construir tecnología entre jurisdicciones. Más sobre el autor.