When a bot restarts, its previous task may still be pending, already completed or left with an uncertain outcome. I need to distinguish those states before retrying. The goal is to recover verifiable work without blindly repeating an action.
If you are still choosing how to start and supervise the process, use the PM2, Supervisor and systemd comparison. This guide focuses on what happens to tasks when that process is interrupted.
Decide what to do with interrupted work
| Verified state | Recovery decision | Evidence needed |
|---|---|---|
| Action did not start | Reschedule only when the previous attempt can no longer perform it. | Durable state and current task ownership. |
| Outcome confirmed | Record the result without executing the action again. | Operation identifier and confirmation from the destination. |
| Outcome uncertain | Reconcile with the destination or request review. | Status lookup, a supported idempotency key or human review. |
Hypothetical example: a bot registers a shipment in an authorized system, but the connection drops before it saves the response. A missing response does not prove the shipment registration failed. I would look up the operation by its identifier. If the destination offers neither a status check nor an idempotent retry, I would stop automatic retries.
A local lock cannot cancel a remote request already sent. The guide to work queues for mobile bots covers task and device allocation. This check focuses on resolving task state after an interruption.
Durable state and bounded retries
Put tasks in a durable queue, acknowledge them after saving state and make repeated execution safe where possible. Store checkpoints outside process memory. Use bounded retries with backoff and manual review. For third-party platforms, operate within authorized use, published limits and applicable terms; a restart loop must never become an uncontrolled request flood.
Graceful shutdown and deployment
On termination, stop accepting work, finish or safely release the current task, flush logs and close connections. Set a realistic stop timeout. Deploy versioned releases, run a smoke test and retain a documented rollback path.
Common mistakes
- running bots in an SSH session
- using unlimited restarts without delay
- keeping queue state only in memory
- starting duplicate workers for one account
- retrying non-idempotent actions blindly
- running as root
- committing secrets
- letting logs and screenshots fill the disk
- monitoring uptime but not completed work
Practical production checklist
- use a least-privilege service account
- set absolute paths and working directory
- validate environment and secrets at startup
- define restart delay, rate limit and memory ceiling
- handle termination signals
- use durable queues, locks and checkpoints
- make retries bounded and observable
- rotate logs and traces
- alert on stale work, crashes and queue age
- test reboot, network failure and rollback
Monitoring useful work
Track successful tasks, failure categories, duration, queue age, retries and time since the last valid result. Add correlation IDs without recording credentials or unnecessary personal data. See what bot logs should store and how to scale bots safely.
The SwimUpvote case shows runs and operational evidence. It illustrates how a task can be investigated; it does not establish that any integration can repeat actions without duplicate effects.
Scope a recovery review
If restarts repeat actions or leave work unfinished, I would trace one task: initial event, stored state, external action, confirmation and retry decision. I would propose testing interruptions before the action, after sending it and after confirmation, using test data and agreed expected outcomes.
The handover should include a recovery policy, evidence and an owner for uncertain states. Explore my automation services or tell me which task fails to recover so we can scope the work.