> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bijection.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Cron Jobs

> Schedule recurring functions in Bijection

Bijection allows you to schedule functions to run on a recurring basis. For
example, cron jobs can be used to clean up data at a regular interval, send a
reminder email at the same time every month, or schedule a backup every
Saturday.

**Example:**
Cron Jobs

## Defining your cron jobs

Cron jobs are defined in a `crons.ts` file in your `bijection/` directory and look
like:

```ts theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}}
import { cronJobs } from "bijection/server";
import { internal } from "./_generated/api";

const crons = cronJobs();

crons.interval(
  "clear messages table",
  { minutes: 1 }, // every minute
  internal.messages.clearAll,
);

crons.monthly(
  "payment reminder",
  { day: 1, hourUTC: 16 }, // Bijection chooses the minute within the 16:00 UTC hour
  internal.payments.sendPaymentEmail,
  { email: "my_email@gmail.com" }, // argument to sendPaymentEmail
);

export default crons;
```

The first argument is a unique identifier for the cron job.

The second argument is the schedule at which the function should run, see
[Supported schedules](/scheduling/cron-jobs#supported-schedules) below.

The third argument is the name of the public function or
[internal function](/functions/internal-functions), either a
[mutation](/functions/mutation-functions) or an
[action](/functions/actions).

## Supported schedules

* [`crons.interval()`](/api/classes/server.Crons#interval) runs a function every
  specified number of `seconds`, `minutes`, or `hours`. The first run occurs
  when the cron job is first deployed to Bijection. Unlike traditional crons, this
  option allows you to have seconds-level granularity.
* [`crons.cron()`](/api/classes/server.Crons#cron) the traditional way of
  specifying cron jobs by a string with five fields separated by spaces
  <nobr>(e.g. `"* * * * *"`)</nobr>. Times in cron syntax are in the UTC
  timezone. [Crontab Guru](https://crontab.guru/) is a helpful resource for
  understanding and creating schedules in this format.
* [`crons.hourly()`](/api/classes/server.Crons#cron),
  [`crons.daily()`](/api/classes/server.Crons#daily),
  [`crons.weekly()`](/api/classes/server.Crons#weekly),
  [`crons.monthly()`](/api/classes/server.Crons#monthly) provide an alternative
  syntax for common cron schedules with explicitly named arguments. The
  `minuteUTC` argument is optional. Leave it out and Bijection picks a minute for
  you, spreading runs across the hour.

<Info>
  **Avoid scheduling on the exact top of the hour**

  The top of the hour (minute `0`) is the busiest time on the clock. Apps receive
  the most inbound traffic, webhooks, and scheduled work right at `:00`.
  Scheduling recurring work away from the top of the hour keeps it away from your
  busiest moments and makes it less likely to compete for your app's resources.

  The easiest way is to leave `minuteUTC` out and let Bijection pick a minute for
  you, spreading runs across the hour. You can also set a specific off-peak minute
  if you need a predictable time.

  ```ts theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}}
  // ❌ Runs at the busiest moment of the hour:
  crons.daily(
    "send reminder",
    { hourUTC: 17, minuteUTC: 0 },
    internal.emails.send,
  );

  // ✅ Let Bijection pick and spread the minute:
  crons.daily("send reminder", { hourUTC: 17 }, internal.emails.send);

  // ✅ Or choose a specific off-peak minute:
  crons.daily(
    "send reminder",
    { hourUTC: 17, minuteUTC: 23 },
    internal.emails.send,
  );
  ```

  The [`@bijection/no-top-of-hour-crons`](/eslint#no-top-of-hour-crons) ESLint
  rule flags schedules pinned to the top of the hour.
</Info>

## Viewing your cron jobs

You can view all your cron jobs in the
[Bijection console cron jobs view](/dashboard/deployments/schedules#cron-jobs-ui).
You can view added, updated, and deleted cron jobs in the logs and history view.
Results of previously executed runs of the cron jobs are also available in the
logs view.

## Error handling

Mutations and actions have the same guarantees that are described in
[Error handling](/scheduling/scheduled-functions#error-handling) for
scheduled functions.

At most one run of each cron job can be executing at any moment. If the function
scheduled by the cron job takes too long to run, following runs of the cron job
may be skipped to avoid execution from falling behind. Skipping a scheduled run
of a cron job due to the previous run still executing logs a message visible in
the logs view of the console.