How it works

The console's main jobs, step by step, each with the screen as it looks at that moment. The screens come from a local copy with a made-up demo project, shop, whose queues and jobs are paused. For the whole system at once, see the Flow.

Run work later: tasks in a queue

A task is one HTTP call the console makes for a project: a method, a URL, headers, a body and an auth option. It waits in a named queue until its time, and the queue sends it at the rate it allows, retrying what fails.

1. Make a queue

   A project has its queues; default is always there. A queue sets how fast it sends (calls a second and at once), how it retries (attempts, backoff, the longest it keeps trying), which status codes are never retried, what it logs, its priority, and where failed tasks go (a dead-letter queue).

   

2. Add tasks

   Three ways in:

   • One at a time on Create a task.
   • Up to 50 at once with From a file, whose Download a sample shows what the file holds.
   • From an app, with the project's API key: see For apps.

   

3. The file is checked, then made in one go

   Every task in the file is checked first, as a single create is. Then the whole file is counted against the day's quota at once, and the queue adds the tasks in one request.

   This file was the sample: two tasks, both made.

   

4. A name the queue remembers is refused alone

   Sent a second time, the sample's named task is refused, because the queue still remembers that name, and its quota unit is given back. Its unnamed task gets a new name and is made.

   

5. A mistake stops the whole file

   When any task is wrong, nothing is made. The message names the place in the file: tasks.1.url is the second task's URL.

   

6. The tasks wait in the queue

   Each task waits for its schedule time. This queue is paused, so nothing is sent. A running queue sends each due task within its rate and its limit on calls at once. A 2xx answer means done. Anything else is retried with backoff until the attempts or the time run out; then the task is Failed and kept 7 days to retry or delete.

   

7. Each attempt can be inspected

   A task's page shows the call and every attempt: when, how long, the status or the kind of error, and the first 1 KB of the answer. Never the auth header, a secret or the request's body.

   

Run work on a schedule: jobs and uptime checks

A job runs on a unix-cron schedule in a time zone: it calls a URL, or adds a task to one of the project's queues.

1. Create a job in three steps

   First the schedule (name, frequency, time zone, with the next five runs shown), then the target (a URL or a queue, the method, headers, body and auth option), then the retries, the attempt deadline and what a run does while the last one is still going: skip, wait, or run beside it.

   

2. The jobs list

   Every job with the last run's status, its state, frequency and time zone, its target and its last and next run. Ticked jobs can be run now, paused, resumed or deleted together.

   

3. A job's runs and settings

   Logs lists each run and its attempts; Configuration shows everything the job was given.

   

4. Uptime checks

   A job of kind check calls a URL on its schedule and expects a status range, at most a latency and, if set, a text in the answer. It alerts after the project's failures-in-a-row count, again on recovery, and shows uptime over 24 hours and 7 days.

   

Copy a project's settings with a file

Export and import moves a project's queues, jobs, alert settings and quota as one JSON file: to keep a copy, or to set up another project.

1. Start from the sample

   Download a sample saves a file with one queue and one paused job, with every setting they take. Change it, or import it as it is.

   

2. Preview first

   Preview is a dry run. It shows what would be made or changed, what would be skipped and why, and the secrets and service accounts the file names that this project doesn't have. Nothing changes yet.

   

3. Then apply

   Apply makes and changes everything in one go, with one line in the audit log. An import never deletes, and never makes a secret or a service account.

   

4. The job arrives paused

   The sample's job is made paused, so it calls nothing until someone resumes it.

   

Stay within the free plan, and know when something is wrong

The whole console runs on Cloudflare's free plan. It counts what it uses and tells people before a limit is reached.

1. The dashboard

   Failures in the last 24 hours, the free-plan meters, the cron's heartbeat, failing jobs and backlogs, for every project the person may read.

   

2. Usage and quotas

   Each project may make 5,000 tasks and runs a day unless an admin sets another cap. Near a free limit (80%) low-priority queues are held and the admins alerted; over it, everything waits until the next UTC day. See Limits and free plan.

   

3. Alerts

   By email and to a Google Chat webhook: a task failed for good, a job failing in a row and recovered, a queue's backlog. Quiet hours can hold them until a window ends.

   

4. Maintenance

   A switch per project, and one for the whole console, holds sending while a deploy or migration runs: tasks are still accepted and wait, scheduled runs are skipped and logged. Every page shows a banner while one is on.

   

Who can do what

People come in only by invitation; apps only with their project's key. See Security and access for the whole design.

1. People and their permissions

   Admins may do everything. A member is given permissions per project: read, create, update, delete, pause, run, keys and secrets.

   

2. API keys for apps

   Each key belongs to one project and reaches nothing else. It is shown once, kept only as a hash, and can be revoked or rotated.

   

3. Secrets, by name only

   Tasks and jobs name a secret or service account, never hold its value. Each secret lists the origins it may be sent to.

   

Screenshots from a local copy of the console, as it is on main, with made-up demo data, 22 Oct 2026.