Which plan to choose for Scheduled Jobs
A Scheduled Job runs a task at times defined by cron and then exits. Billing is per minute of execution, so the plan defines how much each minute costs and how much CPU and memory the task has to finish its work.
The rule of thumb is simple: choose the smallest plan on which the task finishes without running out of memory. A larger plan costs more per minute, but it may finish the same task in fewer minutes.
Quick summary
| Plan | vCPU | RAM | Focus | Typical examples |
|---|---|---|---|---|
job-starter | 0.1 | 64 MB | Short, light tasks at minimum cost | Call a URL, send a ping, clean up files, shell script |
job-basic | 0.5 | 512 MB | Application scripts with dependencies | Node.js or Python script that uses the database, sending emails, syncing with APIs |
job-premium | 1 | 1 GB | Heavy tasks, with per-run metrics | Reports, data exports, file processing, logical backups |
Every plan allows up to 60 minutes per run, scheduling in UTC, logs for each run and optional persistent storage. See the details in Limits and quotas.
job-starter
Focus: very short tasks that use little memory and finish in seconds.
With 0.1 vCPU and 64 MB, job-starter is ideal for tasks that call something and exit. In our tests, small images (such as Alpine with a shell) and minimal Python or Node.js scripts started and finished normally, taking 2 to 4 seconds just to start the interpreter.
- Good for: calling an endpoint of your application with
curlorwget(for example, to trigger a routine), sending a heartbeat to a monitoring service, deleting old files from a volume, simple shell scripts. - Not ideal for: scripts that install or load many dependencies, connect to a database through an ORM or process large files. These tasks tend to be slow or run out of memory; use
job-basic.
job-basic
Focus: the default plan for application scripts.
With 0.5 vCPU and 512 MB, job-basic runs Node.js, Python or Bun scripts with your project's dependencies.
- Good for: sending emails or notifications in batches, syncing data with external APIs, refreshing caches, generating sitemaps, maintenance tasks that access the database through the application's ORM.
job-premium
Focus: heavy tasks and tracking resource usage.
With 1 vCPU and 1 GB, job-premium finishes CPU- or memory-heavy tasks faster. It is the only Job plan with per-run CPU and memory metrics, useful to know whether the task is close to its limit.
- Good for: large reports and exports, processing images, spreadsheets or PDFs, file imports, logical database backups, billing routines.
How to tell whether the plan is right
| Sign | What to do |
|---|---|
| The run ends with an error without a clear message and the logs stop abruptly | Probably out of memory; use a plan with more RAM |
| The run takes many minutes and uses the CPU the whole time | Try a larger plan; it may finish in fewer minutes and cost less in total |
| The run gets close to 60 minutes | Split the task into smaller parts or use a larger plan |
Frequently asked questions
Do I pay while the Job is preparing to run?
No. Billing starts when the task starts running and is per minute of execution, rounded up. See Scheduled Jobs.
Can I use a Job instead of an always-on HTTP project?
Yes, when the task runs at defined times. A worker that must keep listening to a queue all the time should be an HTTP project or use Queues.
Next steps
Last updated on
Which HTTP plan to choose for your application
What each Zenifra HTTP plan is for, from Free to Deep Learning, with examples of applications that run well on each one and signs that it is time to switch.
Which database plan to choose
What each Zenifra plan for PostgreSQL, MariaDB, Valkey Key-Value and Analytics is for, with examples of uses that make sense on each one.