Background tasks#
Some operations take too long to answer a request with. CommandCenter runs those as background tasks: durable work items with a step-by-step log you can watch while they run.
Find them under Background tasks in the navigation, or follow the link in the toast you get when you start one.
What you see#
The list shows every task, newest first, filterable by status and type.
| Status | Meaning |
|---|---|
| Queued | Accepted, not started. A task can be queued for a future date — see Scheduled for. |
| Running | A replica has claimed it and is working through the steps. |
| Succeeded | Every step completed. |
| Failed | A step failed, or the replica running it stopped repeatedly. The reason is on the task page. |
| Cancelled | Stopped before or between steps, either by you or because it could not be recovered. |
Opening a task shows its steps as they happen — name, how long each took, and a running count for steps that process many rows. A step that is still going shows a spinner rather than being hidden, so a task that stops halfway still tells you where it got to.
The page updates live when it can. If your connection or a proxy will not stream, it falls back to refreshing every couple of seconds; the outcome is the same either way.
Cancelling#
Cancel task stops a task that has not finished.
- A task that has not started yet stops immediately.
- A running task stops between steps, not in the middle of one. That is deliberate: it leaves the data in a coherent state rather than half-finished. It may take a moment.
- A task that has already finished cannot be cancelled.
Deleting a customer environment#
This is the operation most people meet the task page through.
On a customer's environment panel, Delete environment appears only when the environment is both offline and inactive. You confirm by typing the environment's name, and the server checks again independently — if someone brought it back online while the task was queued, the deletion stops rather than proceeding.
What happens then, in order:
- The environment is looked up and re-checked.
- Its server log rows are deleted, in batches, with a running count.
- Deploy logs, tool schedules and exception logs are kept but unlinked from the environment; processing status rows are deleted.
- The environment itself is removed. It disappears from the Customers page.
- A second task is scheduled to drop the environment's database in seven days.
The seven-day window is your undo#
The environment's rows go immediately, so the deletion visibly takes effect. The database is kept for a week.
That second task appears in the list straight away as Queued, with Scheduled for showing the date it will run. Cancel it and the database is kept. This replaces the old behaviour, where the only way to stop a deletion was to set the customer back online within seven days.
After it runs, the database is gone and only a restore from backup will bring it back.
What is deliberately left behind#
Two things are not cleaned up automatically, and are known:
- Rows in
CustomerStageAdmin, which lives in a different database. - Two caches — the analytics schema cache and the BenefitManager proxy's routing map — keep the deleted environment for a few hours until they expire on their own.
Retention#
Finished tasks are removed after 30 days by the background-task-prune scheduled job, which you can
see and adjust on Config → Scheduled jobs. It ships in dry-run, so until an operator turns
that off it reports what it would remove without removing anything.
If something fails#
The task page shows the failing step and the error. Tasks are safe to be retried — a replica that stops unexpectedly has its work picked up by another, which starts again from the first step and skips what is already done. After three attempts a task is failed and left for a human.
A failed database drop is never retried automatically: the database is left in place and needs someone to look at it.