Falló una automatización: qué comprobar antes de reintentar

Una automatización marca error y alguien propone pulsar «Reintentar». Antes conviene responder una pregunta más concreta: ¿qué falta por hacer? Puede faltar la acción, su confirmación o un paso posterior. Repetir el flujo completo sirve para una de esas situaciones y puede empeorar las otras.

Para un fundador o un equipo pequeño, la investigación debe poder continuar aunque no esté quien montó la integración. Esta guía entrega una cronología y una ficha para distinguir lo comprobado de lo desconocido. El ejemplo es ficticio: no describe una incidencia de Frihet ni utiliza servicios, clientes o credenciales reales.

El error de la pantalla y el estado del trabajo

Un timeout indica que una espera terminó sin respuesta a tiempo. Por sí solo no permite saber si el destino guardó algo. AWS explica este problema con una petición que podría haber creado un recurso aunque el solicitante no recibiera confirmación. Resolver esa incertidumbre exige identificar el efecto y su origen.

Trabaja con tres estados: efecto confirmado, ausencia de efecto confirmada y desconocido. «No aparece en mi pantalla» pertenece al tercero mientras pueda haber filtros, otra cuenta, un índice atrasado o una ejecución todavía activa. Anota también quién comprobó el estado y a qué hora: una observación tiene contexto, no validez eterna.

Una cronología que cambia la decisión

Supongamos un flujo que crea una tarea interna y después registra su referencia en una hoja de seguimiento. Todo lo que sigue es hipotético. Los tiempos usan el mismo reloj simulado; en una investigación real conserva zona horaria y procedencia de cada marca.

El siguiente paso es recuperar el seguimiento mediante su procedimiento documentado. Reiniciar desde «crear tarea» volvería a tocar algo ya resuelto. Si la última fila solo dijera «no lo veo en la hoja», aún tendríamos que descartar un retraso, un filtro o un proceso activo antes de escribir ahí.

La referencia de operación permanece estable; el identificador de intento cambia con cada ejecución. Un evento recibido y una tarea creada también tienen identidades distintas. Conserva sus relaciones para no confundir dos intentos de un mismo trabajo con dos trabajos legítimos.

Guarda una ficha que otra persona pueda continuar

Empieza por conservar los registros existentes y contener nuevas escrituras con el mecanismo de pausa previsto para ese flujo. Una pausa no deshace lo ejecutado ni garantiza detener peticiones que ya están en curso. Revisa la cola y los reintentos pendientes antes de asumir que nadie más actuará.

Copia esta ficha en un registro interno con acceso adecuado. Usa referencias a evidencias, evitando pegar secretos o datos personales en documentos compartidos. Cada corrección debe añadirse con fecha, sin borrar la observación anterior.

Incidente: [referencia interna]
Operación deseada: [un único resultado concreto]
Proveedor / cuenta / entorno: [contexto del destino]
Operación / evento / intentos: [IDs y relaciones]
Versión del flujo: [versión ejecutada]
Último paso confirmado: [evidencia y hora con zona]
Estado del efecto: [confirmado / ausente confirmado / desconocido]
Evidencia del destino: [referencia, consulta y límites de visibilidad]
Trabajo aún activo: [peticiones, cola y reintentos pendientes]
Contrato de reintento: [documentación, alcance y ventana]
Dato que falta: [prueba necesaria para decidir]
Próxima acción: [consulta o recuperación acotada]
Responsable / próxima revisión: [persona y fecha]
Resultado posterior: [nueva evidencia, sin sobrescribir la anterior]

«Ausente confirmado» necesita una prueba más fuerte que una búsqueda vacía: por ejemplo, un rechazo previo a la ejecución documentado por el destino, con los demás intentos descartados. Si no puedes justificar ese estado, conserva «desconocido».

La clave de idempotencia tiene límites

Comprueba el contrato del proveedor para la petición concreta, cuenta y entorno. Una clave que protege una escritura no protege automáticamente una notificación posterior ni otro servicio. Tampoco se puede añadir retroactivamente a una petición que ya salió sin ella. La ficha debe enlazar la documentación aplicable, no solo decir «tenemos idempotencia».

En Stripe, las peticiones idempotentes — API v1 reutilizan el resultado guardado de la primera ejecución, incluidos errores 500. Stripe compara parámetros y puede eliminar claves después de al menos 24 horas; reutilizar una clave eliminada inicia otra petición. Su guía de errores advierte de efectos posibles tras un 500: cambiar la clave o esperar a que caduque no demuestra que sea seguro repetir una acción incierta.

El plazo anterior pertenece a Stripe. Para otro destino, anota su propia ventana, la identidad que considera repetida y el tratamiento de las peticiones concurrentes. Si una recuperación exige cambiar parámetros, trátala como una decisión nueva, con revisión de los efectos anteriores.

Decide desde la evidencia, paso a paso

La siguiente tabla es un criterio operativo propuesto, no una política universal del proveedor. Separa la investigación de la autorización para modificar datos.

Las escrituras irreversibles o de alto impacto necesitan revisión humana de la recuperación propuesta. Ni una clave ni un botón verde ofrecen una garantía de «exactamente una vez» para todo el recorrido.

Comprueba también quién volverá a intentarlo

Puede que el automatizador, el cliente de API y el proveedor tengan reintentos propios. En los webhooks de Stripe, un reenvío manual no cancela los reintentos automáticos; además, pueden repetirse eventos y llegar fuera de orden. Reenviar un evento tampoco equivale a repetir de forma idempotente una escritura de API: son mecanismos distintos.

Antes de cerrar la ficha, comprueba el estado actual del destino, los pasos pendientes y los intentos que podrían llegar después. Define quién observará la siguiente ejecución. Cerrar la ficha no equivale a resolver el trabajo: si queda un resultado desconocido, mantén la incidencia abierta con responsable y fecha de revisión.

Después puedes revisar si el flujo merece seguir automatizado con el criterio de eliminar, automatizar y delegar. Si conecta Frihet, parte de la documentación para desarrolladores y del catálogo de integraciones para localizar la interfaz correspondiente. Conserva esta ficha junto al flujo: la próxima persona debe poder encontrar el último estado comprobado sin reconstruirlo desde un chat.

Fuentes técnicas consultadas el 14 de septiembre de 2026. Las fichas, decisiones y referencias DEMO son propuestas didácticas propias; no son instrucciones para ejecutar cambios en un servicio real.