WooCommerce, many extensions and half your plugins queue background work here. The table that records it grows faster than your orders and nobody ever looks at it.
Action Scheduler arrived with a plugin rather than a decision, which is why its table is usually the largest one in the database.
Every finished job leaves a row, and the default retention keeps them long enough to reach millions. Pruning runs on a schedule so the table stays a working queue rather than an archive.
Actions are processed by requests, so a quiet period builds a backlog that only clears when traffic returns. Processing runs on system cron instead.
An action that fails repeatedly sits in the queue and blocks nothing visibly. Failures are surfaced rather than left to be discovered when a customer asks.
The scheduler claims a batch of actions per run. Too large and requests time out mid-batch, too small and the queue never catches up.
Knowing what is transient and what is a record matters when restoring, and pending actions are not the same as pending orders.
The symptom is a slow admin and a large database on a site with a modest catalogue. The cause is usually a queue table that has been retaining completed work since launch.
A queue table with millions of rows slows the admin, the scheduler itself, and every backup that has to copy it.
It is shared infrastructure that arrived as a dependency, so nobody owns its configuration until it becomes a problem.
| Setting | What we do | Why |
|---|---|---|
| Completed action retention | Pruned on a schedule rather than kept at the default | Every finished job leaves a row and the default retention is generous enough that the queue table becomes the largest in the database. |
| Queue processing | Driven by system cron rather than by incoming requests | Processing tied to page views means a quiet night builds a backlog, and the actions that were meant to run overnight run at breakfast instead. |
| Failure visibility | Stuck and repeatedly failing actions surfaced | A failed action sits in the queue without breaking anything visibly, so the first report usually comes from a customer whose email never arrived. |
| Claim batch size | Tuned to the site's action mix | Too large a batch times out mid-run and re-claims the same work, too small and the queue never catches up with what is being scheduled. |
| Backup scope | Queue treated as transient, orders as records | Restoring a stale queue can re-run work that already happened, which is a different risk from losing an order. |
Every plan includes free migration, daily backups, SSL and 24/7 support.
Move the site across — migration is free, queue retention reviewed.