We handle
- Scheduling, execution, retry policy, and timeout enforcement
- Execution history, log retention, and failure alerting
- Platform patching and capacity
- Secret injection and private network access
Scheduled Jobs and Workers
Cron that somebody notices when it stops.
What this tier is
The most common cause of a broken nightly job is that nobody was watching. A cron entry on a forgotten machine reports success by saying nothing, and reports failure the same way.
Jobs on this tier record every execution with a start time, a duration, an exit code, and captured output. Failures raise an alert, and so does a run that should have happened and did not. That second case is the one that usually matters.
Specification
| Jobs included | Up to 10 scheduled jobs or workers |
|---|---|
| Compute | 0.5 vCPU equivalent pooled |
| Memory | 1 GB pooled |
| Runtime | Your container image, or a supplied Python or Node runtime |
| History | Execution records with exit code and captured output |
| Alerting | On failure and on missed schedule |
| Networking | Private access to the managed data tier |
What is included
- Up to ten scheduled jobs or long-running workers
- Execution history with start time, duration, exit code, and output
- Alerting on non-zero exit and on missed schedules
- Runs your container image or a script in a supplied runtime
- Private network access to our managed data tier
- Secrets injected at runtime rather than stored in the schedule
- Concurrency and timeout policy configured per job
Typical use cases
- Nightly database exports, report generation, or reconciliation
- Queue workers consuming from a managed cache or broker
- Periodic API synchronisation with a third party
- Certificate, feed, or data refresh tasks that must not silently stop
Responsibility split
Written down so there is no argument about it later.
You handle
- The job itself and its exit code discipline
- Making jobs idempotent enough to survive a retry
- Deciding what counts as a failure worth waking somebody for
How provisioning works
Operator-provisioned. Send the command or image, the schedule, and what should happen on failure. Usually running the same or next business day.
Order
Other tiers in Managed compute and containers
Entry
Container Workload
Your image, running on our cluster, described in a repository.
$14 /mo
- Declarative manifest held in Git, not clicked into a panel
- Public hostname with managed TLS, or internal only
- Restart policy, resource limits, and log access included
View details
Most common
Managed Virtual Server
A real machine with root, and somebody else responsible for the host.
$32 /mo
- Root access on a real virtual machine, not a container
- Scheduled snapshots with off-host backup copies
- Hypervisor, storage, and network operated by us
View details
More cores, more memory, and dedicated CPU rather than burst.
$72 /mo
- Dedicated CPU allocation rather than burst credits
- 8 GB memory and 200 GB storage
- Priority on capacity when we schedule host maintenance
View details
Background reading
- Docker for game servers: clarity over hype Reproducible builds, update flow, and where containers stop helping.
- Double NAT and CGNAT: the silent party crashers Symptoms, diagnosis, and when a hosted relay is the honest answer.