Schedule configuration

A Schedule defines an on-call rotation for a Team: who is on call, in what order, how escalation works, and how VoIP calls behave. A Schedule belongs to a Team, so create the Team first.

Core fields

For members, identify the user by user_id or user_email (email takes precedence). The final-escalation user and all members must be members of the Team.

Each configurations overlay entry takes a required effective_date (start, YYYY-MM-DD), an optional end_date, and its own members list (same shape as the base members above).

VoIP call behavior

These optional fields control how the automated VoIP call to the on-call responder behaves.

Panic broadcast

Like the VoIP fields above, omitting panic_broadcast_enabled from an update keeps the current value — it is not reset to false.

Default bundle (default_bundle)

Every Schedule has exactly one default bundle — the last-resort receiver for alerts that match none of the Schedule's Bundle Settings entries, including alerts that carry no tags at all. It is created together with the Schedule, so there is nothing to add or delete: you only change its parameters, and you do that here rather than on the Bundle Settings pages.

The section is optional, but when you send it, send all eight keys. A partial section is rejected with missing_field, which names the keys you left out — the request never falls back to defaults for them. This is deliberate: without it, an omitted key would be read as its zero value and written back, and four of the eight (description, auto_resolve_on_info, and both cooldowns) are perfectly valid at their zero value, so they would change silently. Omitting auto_resolve_on_info, for example, would quietly stop info alerts from resolving the bundle. Edit the document you read back rather than assembling a partial one — a GET always returns all eight keys.

Omitting the section entirely, or sending it as null, keeps the current values; there is no way to reset the default bundle to the plan default through this section.

The default bundle has no tags: it is the receiver for everything that matched nothing, so there is nothing to select it by. It also has no enabled flag — the last-resort receiver cannot be turned off.

Sending either of them — or any other key the section does not define — is rejected, not ignored: the request fails with unknown_field on default_bundle and lists the offending keys, and the editor flags them before you save. This matters when you paste a Bundle Settings entry as a starting point, because those entries do have tags and enabled: silently dropping them would let you believe you had switched the last-resort receiver off when you had not. The invariants themselves are also enforced by database constraints, so no path can create a default bundle that carries tags or is disabled.

Changes to this section are recorded in the Schedule's own version history, and a rollback of the Schedule configuration restores the default bundle parameters along with everything else.

Ops-mode overrides (ops_config)

ops_config is an object of temporary, safety-side overrides for the settings above. It is read-only in this document: it appears in the configuration you read, but a PUT of the configuration never changes it — it is edited only in Ops mode, and it is deliberately excluded from version history, diffs, and rollback (so an operational stop is not silently undone by rolling a spec back).

Every key is a boolean that, when true, forces the corresponding setting to its safe side regardless of what the configuration above says (effective = configured AND NOT disabled). A key that is false or absent changes nothing.

voip_input_mode, voip_confirm_retry_interval_seconds, voip_confirm_max_retries, reconnect_window_seconds, and flapping_reconnect_threshold have no Ops override — they are not booleans, so there is no unambiguous safe side to force. Their configured values are used as-is.