See failed background work
A synchronous plugin step runs inside the save. If it refuses, the person saving sees the refusal immediately and nothing is written.
An asynchronous step is different, and the difference is the reason this screen exists. It runs after the record has already been saved. The save succeeded, the person who made it has moved on, and if the step then fails there is nobody to tell.
Failed background work is where those go.
What you are looking at
In the Admin area, choose Failed background work. It is beside the audit log, and for the same reason: both are a record of what an environment did, rather than something you author. It is not inside a solution — the queue belongs to the environment, so one list covers everything running in it, whichever solution the work came from.
An empty list is the good state — it means nothing has been given up on. Work that is still running is not listed here; a step that is going to be retried in twenty minutes is not a problem yet.
| Column | What it tells you |
|---|---|
| What failed | The step, and the table whose write triggered it |
| Kind | Usually Plugin step. Processes use the same queue and appear here too |
| Last error | What went wrong the last time it was tried |
| Attempts | How many tries it had before the platform gave up |
| When | The moment of the save that queued it |
Select a row and choose Inspect to see the whole message — including the record's values as they were at the moment it was saved, which is usually what tells you why it failed.
How something ends up here
When an asynchronous step throws, the platform does not give up straight away. It retries five times, waiting longer each time — one minute, then five, then twenty-five, then just over two hours. That covers the common case, which is that the step was right and the world was briefly wrong: a service was down, a record was locked, a network call timed out.
Only after all five have failed is the message given up on and listed here. It is kept, never deleted — the row survives with its payload and its error precisely so you can read it.
Retry
Retry puts the message back on the queue with a fresh set of attempts, so it gets the full five again rather than one last chance. Use it once you have fixed whatever was wrong.
The work runs within a minute or so. If it succeeds it simply disappears from this list; if it fails again, it comes back after the retries are exhausted.
Discard
Discard deletes the message for good. It will never run.
Use it when the work is never going to succeed — the record has since been corrected by hand, the step has been rewritten, the thing it was trying to reach no longer exists. This is the only place in the platform that removes queued work, and it takes a person deciding.
Discard rather than leaving it. A list with permanent residents is a list nobody reads, and then the next real failure is invisible again — which is exactly the problem this screen solves.
"That failure is no longer waiting"
You reloaded a list that was a few minutes old, and somebody else has already retried or discarded that row — or your own retry succeeded and it is gone. Reload and look again.
What it does not show
- Work that is still going to run. A queued or retrying message is not a failure yet.
- Synchronous step failures. Those are refused at the moment of the save, and the person saving is told there and then. There is nothing to catch up on afterwards.
- Failures from another environment. The queue lives in the environment, so switch environments to see its own.