Automator hosting where the queue actually drains.
One trigger fires three actions, one of which calls an external service. Multiply that by every user action and the site is now a job queue with a blog attached.
Every action is somebody else's request.
Automation turns one visitor doing one thing into several outbound calls, and the failure modes are all about what happens while those run.
A queue that empties on schedule
Background actions only run when something triggers the scheduler. Driven by system cron instead, the queue drains on a timetable rather than whenever the site happens to get traffic.
External calls that do not block a page
A recipe calling a CRM or a mailing list is waiting on somebody else's server. Those run in the background, so a slow third party is a delayed action rather than a hung checkout.
Retries that back off instead of storming
When an external service goes down, every queued action fails and retries at once. Backoff is what stops a supplier outage becoming a self-inflicted one.
Recipe logs that stay bounded
Every run of every recipe is recorded. On a busy site that is the fastest-growing table in the install, so retention is set deliberately rather than left to fill the disk.
Recipes that fail loudly
A silent failure means an automation everyone believes is running. Failures are visible rather than swallowed, so a broken recipe is noticed the same day.
Automation is a backlog problem.
Nobody notices automation working. They notice it lagging, and lag is what happens when actions arrive faster than the queue drains.
- Queue drained by system cron, not page views
- Outbound calls executed in the background
- Retries spaced with backoff
- Recipe log retention set deliberately
The page does not wait for the API.
The measure here is not automation throughput. It is whether a visitor's page load is affected at all by the three actions their click just triggered.
What we change for Automator
Each row is about separating what the visitor waits for from what the site does afterwards.
| Setting | What we do | Why |
|---|---|---|
| Queue processing | Driven by system cron rather than visitor traffic | Background actions on a stock install only run when somebody loads a page, so a quiet hour becomes a backlog nobody scheduled. |
| Outbound requests | Executed asynchronously, never inside the page request | A recipe calling an external service is waiting on infrastructure you do not control, and doing that inline hands your response time to somebody else. |
| Retry policy | Spaced with backoff after repeated failure | When a third-party service goes down every queued action fails together, and immediate retries turn their outage into an outage of your own. |
| Recipe log retention | Bounded with a stated window | Every run of every recipe is written down, which on a busy site outgrows the content tables and eventually the disk. |
| Failure visibility | Surfaced rather than swallowed | The worst automation failure is a quiet one, because the business keeps assuming a process is running for weeks after it stopped. |
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 do my recipes run late?
Can an automation slow down the site?
What happens if an external service goes down?
The logs table is enormous. Is that expected?
Let the automation keep up.
Move the site across. Migration is free, recipes and logs included.