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. Omitting one of them from an update keeps its current value — it is not reset to the default.

While voice input is enabled (voip_input_mode is voice_and_dtmf) and voip_barge_in is ON, voip_skip_confirmation cannot be ON: the update is rejected with incompatible_settings. The check uses the current value of any of the three fields you leave out of the update, so changing just one of them can be rejected too. To skip confirmation, set voip_input_mode to dtmf_only or turn voip_barge_in off in the same update.

Panic broadcast

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

Unreachable on-call members

Once a day, Unit Oncall checks every Schedule and notifies the Organization owners and every member of the Schedule's Team (notification center and mobile push) when the Schedule has people who can't be called:

• Someone on the rotation, an upcoming override, an absence substitute, or the final escalation user is no longer a member of the Organization. Calls skip them, so remove them from the Schedule.
• Someone on the Schedule has no phone registered. Calls can't reach them, so ask them to sign in to the Unit Oncall mobile app.
• Someone on the Schedule (other than an owner) doesn't meet the Organization's MFA or SSO requirement (require_mfa / required_sso_providers). They can't enter the Organization, so ask them to set up MFA or link the required SSO account.
• In the coming days, there is a day when nobody on the rotation can take calls (everyone is no longer a member, locked, or absent with no available substitute). The notification lists the first such day and how many there are.

A new problem is reported on the next daily check. A problem that is still there is reported again periodically until it is fixed. The notification type is schedule_unreachable_members; see Organization settings for how to turn its push or email delivery on or off.

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.