# Complex schedules


> Why a schedule can be too complex to save, why except dates cost more than they look, and what read-only means on the Schedule tab.
The rule editor covers what a schedule usually needs. Two things happen past that point.

## Read-only schedules

A schedule built through the API can be more complicated than three sections and a list of rules can express. When one is, the dashboard shows it **read-only** and says so, and it stays editable through the API.

Nothing is broken and nothing is lost. The playlist plays exactly as the predicate says. You just cannot edit it by clicking.

The same applies to a shared playlist: its schedule belongs to the workspace that owns it.

## Too complex to save

Very large schedules are rejected on save as too complex to compile.

The reason is worth knowing because it is not obvious. A rule with **except dates** cannot be expressed as one range: skipping Christmas Day turns "all of this year" into "1 January to 24 December, or 26 to 31 December". Each excluded date splits the range again, and the pieces multiply when combined with other rules.

A handful of holidays is fine. A year of public holidays across five countries in one rule is not.

## Working around it

**Split the intent across several simpler rules** rather than one elaborate one.

**Use several playlists** where the excluded dates differ by region. A rule per country in one playlist is exactly the shape that explodes; a playlist per region, each targeting that region's [label](/docs/labels/), stays small and is easier to read besides.

**Reach for a date range instead of exceptions** where you can. "Closed for two weeks in August" is one gap, not fourteen except dates.

## Where the limit comes from

The schedule is compiled to a small program that runs on the device, and the device has a fixed ceiling on how large that program can be. The cap exists so a schedule cannot be built in the dashboard that a screen then fails to run.