Action Scheduler hosting for the biggest table on your site.
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.
The infrastructure nobody configured.
Action Scheduler arrived with a plugin rather than a decision, which is why its table is usually the largest one in the database.
Completed actions that do not accumulate forever
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.
A queue that drains without visitors
Actions are processed by requests, so a quiet period builds a backlog that only clears when traffic returns. Processing runs on system cron instead.
Stuck actions that are visible
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.
Claim batches sized for the work
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.
The queue is not backup-critical, the orders are
Knowing what is transient and what is a record matters when restoring, and pending actions are not the same as pending orders.
Millions of rows nobody asked for.
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.
- Completed actions pruned on a schedule
- Queue processed by system cron
- Failed and stuck actions surfaced
- Claim batch size matched to the work
The table shows up everywhere.
A queue table with millions of rows slows the admin, the scheduler itself, and every backup that has to copy it.
What we change for Action Scheduler
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. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Why is my database so large with only a few thousand orders?
Why do scheduled actions run late?
How would I know an action failed?
Should the queue be in backups?
Take ownership of the queue.
Move the site across. Migration is free, queue retention reviewed.