---
title: Schedules
description: The same experiment, launched without you.
---

A schedule repeats an experiment you already have. There is no second builder,
because saying the same configuration twice in two different forms is how the
two drift apart.

## Creating one

From the **Schedules** page, press *New schedule*; or from any experiment, press
**Schedule** and the dialog opens on it.

1. **Pick the experiment to repeat**

    The dialog says what that means in runs: *2 tasks × 3 agents = 6 runs every
    time it fires, with 1 asset attached*.

2. **Choose a cadence, in words**

    Every few minutes, hourly, daily, weekly or monthly. Each option asks only
    for what it needs — an interval, a time of day, days of the week, a day of
    the month — so there is never a field on screen that does nothing.

3. **Check the preview, then save**

    The dialog shows the cadence in plain English and the next three firings, in
    your own timezone, worked out with the same library the server ticks on. It
    is a preview of what will really happen, not a second opinion about it.

> **What it copies is frozen**
>
> A schedule copies the experiment's whole configuration — tasks, agents,
> attached assets and files, rubric, machine, trials, concurrency — at the moment
> you create it. Editing or deleting that experiment afterwards never changes
> what fires tonight.

## Timezones

The cadence is stored with the timezone of the browser that saved it, and the
Schedules table says which one it is showing times in. "Every weekday at 9" is a
claim about your morning; reading it in the server's timezone would fire it at
the wrong hour of yours.

## The table

| Column | What it says |
|---|---|
| **Repeats** | The size of one firing: tasks × agents, and anything attached. |
| **Cadence** | In plain English. Hover for the underlying expression and timezone. |
| **Next** | When it fires next, or *paused*. |
| **Last** | When it last fired — a link to the experiment it produced. |
| **Launched** | How many experiments it has produced in total. |
| **Enabled** | The switch. A paused schedule keeps everything and simply stops firing. |

Two actions per row: **run it now** (which does *not* move the cadence — tonight
still happens), and **delete** (which keeps everything it already launched).

## Two rules worth knowing

1. **Missed firings are not made up**

    A laptop closed for a week comes back to one launch, not seven queued behind
    each other. The point of a nightly check is last night's answer; six stale
    copies of it would cost real money and tell you nothing. Restarting the
    server is likewise not a way to fire a slot that has already passed.

2. **A firing that cannot launch is recorded, not retried**

    The usual reason is one of your own agents whose `redline dev` is not
    running. Nothing about that resolves in thirty seconds, so the schedule
    writes the reason down — it appears as a warning on the row — and waits for
    its next slot.

## What it produces

Ordinary experiments. Each firing is named after the schedule with a timestamp,
is marked on its own page as launched by a schedule, and its runs appear in
**All runs** like any other. There is no separate place to look at scheduled
results, because a result nobody was present for is not a different kind of
result.