# Work schedule library

Work schedules for servers in the schedule run mode: the server runs during the schedule windows and sleeps outside them. The library is shared across the Bitrix24 account — one schedule can be assigned to many servers, and editing its windows immediately changes when every assigned machine runs.

**Preset and custom schedules.** The platform provides the presets: `weekdays-9-18` — weekdays from 9 to 18, `weekdays-9-19` — weekdays from 9 to 19, `weekdays-9-20` — weekdays from 9 to 20, `weekdays-8-19` — weekdays from 8 to 19, `weekdays-8-20` — weekdays from 8 to 20, `daily-9-21` — every day from 9 to 21. They cannot be edited or deleted: for a different weekly pattern, create a custom schedule. The set of presets keeps growing, so a key missing from this list means a preset newer than this page, not an error. A Bitrix24 account can keep up to 50 custom schedules.

**Week windows.** A window is an object `{ isoDay, start, end }` in the schedule's local time: `isoDay` from 1 (Monday) to 7, `start` and `end` as `HH:MM` in 30-minute increments, with `24:00` for the end of the day. A window lasts at least an hour and never crosses midnight. A day holds up to two windows, at least 30 minutes apart.

**Who can edit.** A custom schedule can be edited and deleted by its author or by an administrator of the Bitrix24 account. The `canEdit` field in the response indicates whether the key owner may do so.

**Before run modes are enabled.** The library can always be read. Creating, editing and deleting, like [setting a server's run mode](/docs/infra/lifecycle/run-mode), return `400 RUN_MODE_UNAVAILABLE` until run modes are enabled for the Bitrix24 account. Until then the library is empty: the presets appear in it together with the run modes.

**Schedule for new machines.** An administrator of the Bitrix24 account can mark the schedule new machines are born on, so a new machine does not have to be moved to a schedule after it is created. There are two marks — one for servers and galaxy applications, one for agents and bots. An agent on a schedule sleeps outside its windows and answers no messages until the next window opens, so agents have a mark of their own. The mark does not touch machines that already exist.

Scope: `vibe:infra`

## Operations

- [List schedules](./work-schedules/list.md) — `GET /v1/work-schedules`
- [Get a schedule](./work-schedules/get.md) — `GET /v1/work-schedules/:id`
- [Create a schedule](./work-schedules/create.md) — `POST /v1/work-schedules`
- [Update a schedule](./work-schedules/update.md) — `PATCH /v1/work-schedules/:id`
- [Delete a schedule](./work-schedules/delete.md) — `DELETE /v1/work-schedules/:id`
- [Set the default schedule](./work-schedules/set-default.md) — `PUT /v1/work-schedules/:id/default`

## Typical scenario

1. Find a matching schedule in the [list](./work-schedules/list.md) or add a custom one by [creating it](./work-schedules/create.md).
2. Assign it to a server — [`PATCH /v1/infra/servers/:id/run-mode`](/docs/infra/lifecycle/run-mode) with `mode: "SCHEDULE"` and `scheduleId`.
3. Change the windows for all assigned servers at once — [update the schedule](./work-schedules/update.md) with the current `version`.
4. To have new machines born on the schedule right away, [mark it as the default](./work-schedules/set-default.md) with `audience: "machines"`.

## See also

- [Infrastructure](/docs/infra)
- [Set the server run mode](/docs/infra/lifecycle/run-mode)
- [Scheduled wake](/docs/infra/wake-schedules)