Scheduled tasks: run a job on your site at set times
A scheduled task runs something on your site at set times without anyone pressing a button: a summary every morning, a tidy up every Sunday night. You find them in the project's Settings, under Scheduled tasks. This page shows how to set one up, read its runs and fix one that fails.
What a scheduled task does
A scheduled task is a call Briks makes on a schedule. It calls either a route on your site (an address under /api/ that runs code rather than showing a page) or another public https address, such as a service you use. The address does the work. Briks makes the call on time and records what came back.
So a task needs something to call. If your site has no route for the job yet, ask for one in the studio first, then point a task at it. With no tasks yet, the page says No scheduled tasks and sums up the usual jobs: to send a daily digest, tidy old records or sync with another service.
Tasks run whether or not the site is published, at the times you set, in the time zone you choose. The section has three views: Tasks, Runs and Settings.
Limits on each plan
| Plan | Scheduled tasks per project | Calls a day per project |
|---|---|---|
| Free | 1 | 2,000 |
| Starter | 5 | 5,000 |
| Pro | 10 | 10,000 |
| Studio | 25 | 50,000 |
| Agency | 50 | 100,000 |
The Tasks view shows where you stand, such as 2 of 5 on your plan, and Add task is greyed out once you reach the limit. A Get more link then appears beside the count and opens the upgrade window, which names the smallest plan with room for another task. A run that would go past the day's calls is marked Skipped. Plans are compared on Billing.
Add a scheduled task
Press Add task
Where: Settings, Scheduled tasks
The Add a scheduled task dialog opens. Editors, Admins and Owners can add tasks.
Name it
Where: Add a scheduled task
Give it a short name you will recognise in the runs list, such as
Daily digest. Up to 60 characters.Set the schedule
Where: Add a scheduled task
Type a schedule in Schedule or press one of the buttons under it. The next section explains the format.
Choose the time zone
Where: Add a scheduled task
Time zone starts on your own. A box below shows the schedule in words and the next five times it will run there, so you can check it before saving.
Say what it calls
Where: Add a scheduled task
Under What it calls, choose A route on this site and type its path (it starts with
/api/), or Another address and type a full https address. For a route, the hint under the box shows the full address that will be called.Choose POST or GET
Where: Add a scheduled task
POST sends a short message with the call, which most routes built for a job expect. GET only asks for the address. If you're unsure, leave POST.
Save
Where: Add a scheduled task
Press Add task. It is saved only once the scheduler has taken it, so every task on the list is one that runs.
Writing a schedule
A schedule is five values separated by spaces: minute, hour, day of the month, month and day of the week. A * means every. If what you type can't be read, the box says what's wrong, such as which value is out of range.
| You want | Type | The preview says |
|---|---|---|
| Every morning at 7 | 0 7 * * * | Every day at 07:00 |
| Weekdays at half past six in the evening | 30 18 * * 1-5 | Every weekday at 18:30 |
| Every 15 minutes | */15 * * * * | Every 15 minutes |
| Every two hours, on the hour | 0 */2 * * * | Every 2 hours, on the hour |
| Sunday nights at 11 | 0 23 * * 0 | Every Sunday at 23:00 |
| The 1st of each month at 6 in the morning | 0 6 1 * * | On the 1st of every month at 06:00 |
Days of the week run from 0 (Sunday) to 6 (Saturday), and 7 is Sunday too. You can also write names such as mon or jan, lists such as 1,3,5, ranges such as 1-5 and steps such as */10. Shortcuts work as well: @hourly, @daily, @weekly, @monthly and @yearly.
The buttons under the box fill it in for you: Every 5 minutes, Every hour, Every day at 09:00, Mondays at 09:00 and First of the month.
What each call carries
A task waits up to 30 seconds for an answer. Every call carries a user-agent of Briks-Cron/1.0 and an x-briks-cron header holding the task's id, so the route can tell where the call came from. A POST call also sends a short JSON message (JSON is a plain text format programs read) that names the task:
{"cron":{"id":"…","name":"Daily digest"},"trigger":"schedule","scheduledFor":"2026-10-09T06:00:00.000Z"}
trigger is manual when someone pressed Run now, and then scheduledFor is null.
Briks won't call an address on a private network, an address written as numbers, or one of its own addresses, and it doesn't follow redirects, so give the final address. Calls to a route on your site go to its briks.live address, and if you change that address they follow it.
Runs and what each status means
Runs lists every run of the last thirty days, newest first, scheduled or started by hand. A run started by hand carries a By hand tag. With more than one task, pick one in the box above the list and press Show. Click a run to see the method and address it called, any error, and the start of what the address answered.
| Status | What happened |
|---|---|
| Succeeded | The address answered with a 2xx status, the web's code for success. |
| Failed | Anything else: a different status (404 means not found, 500 means the code behind it failed), no answer within 30 seconds, a redirect, or an address that couldn't be reached. |
| Skipped | The project's calls for the day were used up. The run says: Today's calls for this project are used up. Runs start again after midnight (UTC). |
The Tasks view shows the same at a glance: Next and the time of the coming run, Last with the latest status, or Not run yet.
When a run fails
A failed run is recorded and not repeated. The next one comes at its usual time. Runs that were missed while nothing could run them aren't made up either: the task runs once and carries on from there.
Once you've fixed the cause, open the task's three dots and choose Run now. The result appears straight away, for example: Daily digest ran: the address answered 200 in 312 ms. You can run a task by hand up to 20 times an hour, and each run counts towards the day's calls.
| What the run says | What to do |
|---|---|
| answered 404 | There is no route at that path. Check the spelling, and that the version with the route has been published. |
| answered 500 | The route itself failed. Open Logs, choose Requests, and search for the path to read the error. |
| No answer within 30 seconds. | The job takes too long in one go. Ask in the studio for the route to do less per call, and run it more often. |
| Redirects are not followed: use the final address. | Open the address in a browser, copy where it ends up, and change the task to that. |
| That address points to a private network and cannot be called. | Use a public address. Briks never calls into private networks. |
Pause, change or delete
The switch beside each task pauses it (a Paused tag appears) and starts it again. In its three dots, Change opens the same form, titled Change task, and Delete stops it and removes its run history. All of these need edit rights.
The Settings view has Download JSON, a file with every task's name, schedule, time zone and what it calls. Its danger zone holds Clear history (the tasks keep running) and Delete all (you type the project's name to confirm). Both are for Owners and Admins.
Worked examples
Add a route at /api/daily-summary that emails me yesterday's appointment requests in one message.
After the change is published, the clinic adds a scheduled task named Daily summary with the schedule 0 7 * * *, time zone Europe/London, calling POST /api/daily-summary. Each morning at seven the summary arrives.
The summary goes out through the site's own email, which is off until you switch it on. See Site email for how and for the monthly allowance.
Add a route at /api/tidy-enquiries that deletes enquiries older than 90 days.
A task named Tidy enquiries runs it with 0 23 * * 0, every Sunday at 23:00. On Monday, Runs shows Succeeded, and opening the run shows what the route said back.
Before a clean up like this runs for the first time, save a restore point in the Database tab's settings. If the route deletes more than it should, you can go back. See Backups.