--- title: "Scheduled tasks: run a job on your site at set times | Briks" url: https://briks.dev/docs/crons description: "Run a scheduled task on your site at set times: a morning summary, a weekly tidy up. Write a schedule, read each run, fix one that fails, and see plan limits." last_updated: 2026-10-08 --- # 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. 8 minute read Checked against the studio on 8 October 2026 ## 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**. Where 1. Projects 2. Your project 3. Settings 4. Scheduled tasks ## 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 | Calls a day are shared between task runs and webhook delivery attempts, and the day starts at midnight UTC. 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](https://briks.dev/docs/billing). Pick a sensible interval A task that runs every minute makes 1,440 calls a day on its own. On the Free plan, with 2,000 calls a day, that leaves little room for anything else. Every 5 or 15 minutes is plenty for most jobs, and once a day is enough for summaries. ## Add a scheduled task 1. Press Add task Where: Settings, Scheduled tasks The **Add a scheduled task** dialog opens. Editors, Admins and Owners can add tasks. 2. 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. 3. 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. 4. 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. 5. 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. 6. 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. 7. 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**. Two details If you limit both the day of the month and the day of the week, a day matching either one runs. And when the clocks change, a time that happens twice runs once, while a time the clock skips runs just after the change, so a daily 02:30 task never goes missing. ## 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: The body of a POST call > `{"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 Where 1. Projects 2. Your project 3. Settings 4. Scheduled tasks 5. Runs **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](https://briks.dev/docs/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. | Make jobs safe to repeat Anyone who knows a route's address can call it, and you will press **Run now** while testing. Ask for routes that do no harm when run twice: clear records older than 90 days rather than the oldest 50. ## 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. Where 1. Projects 2. Your project 3. Settings 4. Scheduled tasks 5. Settings 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 Asked in the studio A daily summary for a physiotherapy clinic > 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](https://briks.dev/docs/site-email) for how and for the monthly allowance. Asked in the studio Clearing old records for a tutoring agency > 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](https://briks.dev/docs/backups). ## Read next - [Data and automation **Webhooks** Send a signed message to another tool when your site is published, a form is sent or a record changes. Payloads, signatures, retries and deliveries explained.](https://briks.dev/docs/webhooks) - [Data and automation **Logs** Read the build log and the last day of your site's requests, filter by level or status, and track down a failing form, a failing job or a slow page.](https://briks.dev/docs/logs) - [Your site's features **Site email** Let your site send confirmations and replies from its own address on emails.briks.live, choose where replies go, and track sending against a monthly allowance.](https://briks.dev/docs/site-email) - [Data and automation **Database** Find what your site stores, edit and add records by hand, and download collections as JSON or CSV, with who can do what and the limits that apply.](https://briks.dev/docs/database) Still stuck? Write to [hello@briks.dev](mailto:hello@briks.dev) with your project's name and what you expected to see. A screenshot helps.