---
slug: schedules
title: Scheduled runs
---

# Scheduled runs

Schedules let your agents run automatically on a repeating timetable — no human trigger required. Use them for nightly digests, hourly monitoring, weekly reports, or any routine task where the timing matters more than a conversation prompt.

Each schedule fires an agent on a cron expression you define, runs the task's prompt against any connected knowledge and skills, and records the result in the Activity log.

---

## Creating a schedule

Go to **Agentic > Schedules** and click **New schedule**. You can also create schedules through the [task creation wizard](/docs/ask/tasks) or via the MCP tool `create_task_schedule`.

| Field | Description |
|---|---|
| **Name** | A human-readable label shown in the Schedules list (e.g. *Nightly sales digest*) |
| **Task** | The task this schedule fires. The task carries the prompt the agent sees on each run |
| **Agent** | Which agent runs the task. Defaults to the first agent assigned to the task |
| **Cron expression** | When to fire — standard 5-field format (see below) |
| **Timezone** | IANA timezone the cron is evaluated in. Defaults to UTC |
| **Retries** | How many times to retry automatically if the run fails (0–3) |
| **Enabled** | Toggle on/off without deleting the schedule |

---

## Cron syntax

Schedules use standard 5-field cron expressions:

```
┌─ minute      (0–59)
│  ┌─ hour     (0–23)
│  │  ┌─ day   (1–31)
│  │  │  ┌─ month  (1–12)
│  │  │  │  ┌─ weekday (0–7, 0 and 7 = Sunday)
│  │  │  │  │
*  *  *  *  *
```

Common expressions:

| Expression | When it fires |
|---|---|
| `0 9 * * 1-5` | 9:00 am, Monday–Friday |
| `0 8 * * *` | 8:00 am every day |
| `0 */6 * * *` | Every 6 hours |
| `0 9 1 * *` | 9:00 am on the 1st of every month |
| `30 17 * * 5` | 5:30 pm every Friday |

**Minimum interval:** Schedules must fire no more often than every **5 minutes**. Expressions that resolve to shorter gaps (including `*/1 * * * *` or similar) are rejected at save time.

---

## Timezones

The cron expression is evaluated in the timezone you set. For example, `0 9 * * 1-5` with timezone `Europe/London` fires at 9am London time, automatically adjusting for BST/GMT transitions — you don't need to update the expression when clocks change.

Use any [IANA timezone identifier](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) (e.g. `America/New_York`, `Asia/Tokyo`, `Europe/Paris`). The field defaults to `UTC` if left blank.

---

## Retries

If a run fails, the schedule can automatically retry before sending a failure notification. Each retry consumes credits from your balance.

| Setting | Behaviour |
|---|---|
| **0 retries** (default) | Failure → email notification immediately |
| **1–3 retries** | Elaras retries up to that many times; notification only fires if all attempts fail |

The Activity log records each attempt separately so you can see which retry succeeded or what error each attempt produced.

---

## Monitoring schedules

The **Schedules** tab shows every schedule with its current state:

| Column | Description |
|---|---|
| **Last fired** | When the schedule last dispatched a run |
| **Next fire** | When the next run is due (blank if disabled) |
| **Status** | Enabled or disabled |

Click a schedule to edit it. Disabling a schedule clears the next fire time; re-enabling it recomputes the next run from the current time.

To see the results of past runs, go to **Agentic > Activity** and filter by trigger type **Scheduled**.

---

## Limits

| Limit | Value |
|---|---|
| Schedules per team | 20 (active + inactive combined) |
| Minimum fire interval | 5 minutes |
| Maximum retries per run | 3 |

---

## Creating via MCP

If you use the [Ask MCP server](/docs/ask/mcp), you can create schedules programmatically with `create_task_schedule`:

```json
{
  "tool": "create_task_schedule",
  "arguments": {
    "task_id": 12,
    "name": "Nightly sales digest",
    "cron_expression": "0 8 * * *",
    "timezone": "Europe/London",
    "enabled": true,
    "max_retries": 1
  }
}
```

The `chatbot_id` field is optional — when omitted, the first agent assigned to the task is used automatically. Elaras validates the cron expression and returns the computed `next_dispatch_at` in the response.