Background Jobs
Last updated:
Practical patterns for long-running tasks users can trust while they wait or navigate away.
01 — Foundation
Background work should reduce stress
Handled well, background processing improves flow. Handled badly, users lose trust immediately.
Background jobs let long-running tasks continue without blocking the interface. Users still need to know what is processing, whether they can leave safely, how completion is communicated, and whether retry exists when something fails.
02 — Status
Visible status and history
Hidden processing feels like the product froze.
- show job state — queued, running, complete, failed — in context or a jobs panel
- say whether users can navigate away — “You can leave this page; we will email when ready”
- preserve task history so users can check past exports or imports
- avoid “please keep this tab open” unless the architecture truly requires it
03 — Completion
Completion and failure
Silent failure is worse than a slow success.
- notify on completion — inline status, toast, or notification — see Notifications
- link to the result — download, report, or updated record
- retry on failure with specific error — see Retry Patterns
- do not lose progress silently when the user returns later
<p role="status" aria-live="polite">
Export complete. <a href="/exports/1042/">Download file</a>
</p>04 — Accessibility
Accessible background jobs
Completion must be perceivable without staring at the screen.
- announce meaningful state changes — not every percentage tick
- progress bars use accessible names when they represent real progress
- failed jobs use assertive messaging when user action is required
05 — Review
Before you approve
A short checklist for background jobs in code review.
- processing is visible; users know if they can leave
- completion and failure are communicated with next steps
- retry and history are available where appropriate