When a bot fails, “element not found” is rarely enough. The cause may be a stale job, changed interface, expired session, unavailable device, network timeout, rate limit or a business-rule rejection. Good observability makes those cases distinguishable without replaying the entire run.
Give every execution a traceable identity
Create a job ID when work enters the queue and propagate it through every component. Include timestamp, environment, deployment version, worker, device or browser profile alias, action name, attempt number, duration and outcome. Use stable internal identifiers instead of account names or raw personal data.
Structured JSON lets the system group and query events. Define severity and error codes centrally. Human messages can change; codes such as SESSION_EXPIRED, UI_SELECTOR_MISSING and RATE_LIMITED should remain stable.
Log transitions, not every instruction
Record job accepted, resource allocated, session verified, major workflow step completed, external response classified, retry scheduled and final outcome. Add durations to expose slow dependencies. Logging every tap, keystroke or DOM query creates noise and may capture sensitive values.
For queue-driven systems, link parent and child jobs and record idempotency keys. The guide to designing work queues for mobile bots explains why retry state belongs to the job model rather than an improvised loop.
Evidence for difficult failures
On selected failure classes, capture a screenshot, page source or device diagnostics with strict access and retention. Redact tokens, messages, contact details and form values. Store the evidence outside the log payload and reference it with a protected object ID.
For Android, useful technical context can include package and activity, Appium session alias, device state, screen dimensions, network status and a short filtered device-log window. Never dump the complete device or credential store. For public-web automation, follow access terms, limits and authorised use; logs do not legitimise prohibited collection.
Classify the failure before retrying
- transient: timeout or temporary service failure; retry with backoff
- resource: offline device or exhausted worker; reassign safely
- session: expired or challenged session; pause for controlled recovery
- application: selector or flow changed; stop and investigate
- business: valid rejection or limit reached; do not retry blindly
- compliance: consent, access or policy constraint; stop and escalate
Set a finite retry budget and preserve the first cause. A final timeout after five attempts should not erase the original rate-limit response.
Common mistakes
- writing unstructured strings with no job ID
- logging passwords, cookies, tokens or complete payloads
- using account identity as the only correlation key
- taking screenshots on every successful step
- retrying permanent or policy-related failures
- mixing application events and metrics without conventions
- keeping logs forever without a retention policy
- alerting on every exception instead of user impact
Practical checklist
- propagate job, trace and attempt identifiers
- include version, resource alias, action and duration
- use structured events and stable error codes
- redact secrets and minimise personal data
- capture protected evidence only when useful
- classify retryable and terminal failures
- define retention and role-based access
- monitor success rate, latency, retries and queue age
- alert on sustained impact with a runbook link
- test dashboards and alerts during controlled failures
Traceability, stability and alerts
Dashboards should show success by workflow version, device group and error code. Alert when failure rate or queue age exceeds a sustained threshold, not when one expected exception occurs. Keep deployment markers visible so regressions correlate with releases. The broader baseline in logs, alerts and monitoring applies here too.
When hiring a technical person makes sense
Bring in an automation or platform engineer when failures cross queues, devices and third-party services; when evidence contains regulated data; or when retries can duplicate customer actions. They can define the event schema, privacy controls, failure taxonomy, dashboards and recovery runbooks before incidents become expensive.
Final takeaway
The best bot logs tell you what ran, where, with which version, what changed and what should happen next—without exposing the user. If your automation is difficult to diagnose, review my technical services or contact me with the architecture and representative failure codes.