Subscriptions hosting where renewals run on time.
Recurring revenue depends on a scheduler nobody watches. When it drifts, the symptom is not an error page - it is renewals that quietly did not happen.
The invisible part of the store.
Everything that decides whether a subscription business works happens without a visitor on the site.
Scheduled events that stay manageable
Every active subscription schedules its own future events. On a large store that is tens of thousands of pending actions, and where they are stored decides whether the site stays quick.
Retry storms that do not cascade
A failed card is retried on a schedule, and a payment provider outage means thousands retrying together. That burst gets absorbed rather than taking the storefront down with it.
Renewal orders without table bloat
Each renewal creates an order, so a subscription store generates orders faster than a normal one and never stops. Order queries are indexed for that growth rather than for a launch-day catalogue.
A failed payment is not a lost customer
Dunning and retry sequences run predictably, so a customer whose card expired gets the emails at the right intervals rather than whenever cron caught up.
Restore without breaking billing
Subscription state and order history are tied together. Backups cover both, so a restore does not leave customers billed for something the site forgot.
Nobody notices until money is missing.
A subscription store fails silently. The site stays up, the shop works, and the only sign is a renewal batch that did not complete a week ago.
- Scheduled actions stored where they stay fast
- Retry bursts absorbed within plan limits
- Renewal batches given room to complete
- Order tables indexed for continuous growth
Eighteen thousand pending actions, still quick.
The measure here is not page speed. It is whether the scheduler can work through a queue that grows with every subscription you sell.
What we change for Subscriptions
Subscriptions turn a store into a scheduler with a shop attached, and every row here is about the scheduler.
| Setting | What we do | Why |
|---|---|---|
| Scheduled action storage | Kept in indexed tables rather than the options table | Tens of thousands of pending events in autoloaded options are read into memory on every single request, which slows the whole site down for reasons nobody connects to billing. |
| Retry bursts | Absorbed within plan limits | A payment provider outage causes thousands of subscriptions to retry in the same window, which is the largest concentrated write a store ever sees. |
| Renewal batches | Own execution ceiling, run to completion | A partially completed renewal run means some customers were billed and others were not, which is worse than none of them being billed. |
| Order indexing | Tuned for continuous order growth | A renewal is an order, so a subscription store's order table grows on a schedule forever rather than in proportion to traffic. |
| Dunning sequence | Driven by the platform scheduler | Retry emails at the wrong intervals turn a recoverable expired card into a cancellation. |
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 did my renewals stop running?
What happens if the payment gateway goes down?
My site got slow and I cannot find why. Could it be Subscriptions?
Does WooCommerce Subscriptions need a bigger plan than a normal store?
Bill everybody, every time.
Move the store across. Migration is free, subscriptions and schedules included.