Cuando un bot falla, «elemento no encontrado» rara vez basta. La causa puede ser un trabajo obsoleto, una interfaz modificada, una sesión caducada, un dispositivo caído, un timeout, un límite de frecuencia o un rechazo de negocio. Una buena observabilidad permite distinguirlos sin reproducir toda la ejecución.
Da una identidad trazable a cada ejecución
Crea un ID al entrar el trabajo en la cola y propágalo por cada componente. Incluye fecha, entorno, versión desplegada, worker, alias del dispositivo o perfil, acción, intento, duración y resultado. Usa identificadores internos estables, no nombres de cuentas ni datos personales.
El JSON estructurado permite agrupar y consultar eventos. Define severidades y códigos de error de forma centralizada. El mensaje humano puede cambiar; códigos como SESSION_EXPIRED, UI_SELECTOR_MISSING y RATE_LIMITED deben mantenerse estables.
Registra transiciones, no cada instrucción
Registra trabajo aceptado, recurso asignado, sesión verificada, paso importante completado, respuesta externa clasificada, reintento programado y resultado final. Añade duraciones para detectar dependencias lentas. Guardar cada toque, tecla o consulta DOM genera ruido y puede capturar valores sensibles.
En sistemas con colas, enlaza trabajos padre e hijo y registra claves de idempotencia. La guía para diseñar colas de trabajo para bots móviles explica por qué el reintento debe formar parte del modelo del trabajo.
Evidencia para fallos difíciles
En fallos seleccionados, captura una pantalla, fuente de página o diagnóstico del dispositivo con acceso y retención estrictos. Oculta tokens, mensajes, contactos y valores de formularios. Guarda la evidencia fuera del evento y referencia un objeto protegido.
En Android puede ser útil registrar package y activity, alias de sesión Appium, estado del dispositivo, dimensiones, red y una ventana corta de logs filtrados. Nunca vuelques el dispositivo o almacén de credenciales completo. En automatización web respeta términos, límites y usos autorizados; los logs no legitiman una recogida prohibida.
Clasifica el fallo antes de reintentar
- transitorio: timeout o caída temporal; reintento con espera
- recurso: dispositivo offline o worker agotado; reasignación segura
- sesión: sesión caducada o desafiada; recuperación controlada
- aplicación: selector o flujo cambiado; parar e investigar
- negocio: rechazo válido o límite alcanzado; no insistir
- cumplimiento: restricción de acceso, consentimiento o política; parar y escalar
Fija un presupuesto finito de reintentos y conserva la primera causa. Un timeout final tras cinco intentos no debe borrar la respuesta inicial de limitación.
Errores comunes
- escribir cadenas sin estructura ni ID de trabajo
- guardar contraseñas, cookies, tokens o payloads completos
- usar la identidad de cuenta como única correlación
- tomar capturas en cada paso correcto
- reintentar fallos permanentes o relacionados con políticas
- mezclar eventos y métricas sin convenciones
- guardar logs para siempre sin política de retención
- alertar por cada excepción en vez de por impacto
Checklist práctico
- propagar IDs de trabajo, traza e intento
- incluir versión, alias de recurso, acción y duración
- usar eventos estructurados y códigos estables
- ocultar secretos y minimizar datos personales
- capturar evidencia protegida solo cuando aporte valor
- clasificar fallos reintentables y terminales
- definir retención y acceso por roles
- medir éxito, latencia, reintentos y edad de cola
- alertar por impacto sostenido y enlazar un runbook
- probar dashboards y alertas con fallos controlados
Trazabilidad, estabilidad y alertas
Los dashboards deben mostrar éxito por versión del flujo, grupo de dispositivos y código. Alerta cuando el error o la edad de cola supere un umbral sostenido, no por una excepción esperada. Marca despliegues para relacionar regresiones con versiones. La base de logs, alertas y monitorización también aplica aquí.
Cuándo tiene sentido contratar a alguien técnico
Busca un ingeniero de automatización o plataforma cuando los fallos cruzan colas, dispositivos y terceros; cuando la evidencia contiene datos regulados; o cuando un reintento puede duplicar acciones. Puede definir eventos, privacidad, taxonomía, dashboards y runbooks antes de que los incidentes sean caros.
Conclusión
Los mejores logs explican qué se ejecutó, dónde, con qué versión, qué cambió y cuál es el siguiente paso, sin exponer al usuario. Si tu automatización es difícil de diagnosticar, revisa mis servicios técnicos o contacta conmigo indicando arquitectura y fallos representativos.