Documentation

    Schedules and overrides

    A schedule says who is on call at any instant. It is built from rotations that hand the duty from one participant to the next at a fixed cadence, in the team’s time zone, and from overrides that put one person on call for a while whatever the rotation says.

    What a schedule is made of

    • A schedule has a name (letters, digits, dots, underscores and hyphens, up to 100 characters), an IANA time zone such as America/New_York or Europe/Madrid, an optional description, an enabled switch, and one or more rotations.
    • A rotation has a cadence (daily, weekly or a custom length), a first hand-over instant, an optional end, an ordered list of participants with how many turns in a row each one takes, and optional active hours.
    • An override is a person, a start and an end. For that period the override is who is on call, whatever the rotations say.

    A disabled schedule has nobody on call: an escalation step or a routing rule that targets it pages no one, and its calendar is empty. A team on the Free plan can have 2 schedules, with as many rotations and overrides in each as it needs.

    The schedules of a team in the IgniteOps console: Platform Primary and Secondary, who is on call now on each, the next hand-over and the enabled switch
    The Schedules tab: each schedule with its rotations, who is on call now, and when the next hand-over is.

    Rotations and hand-overs

    The cadence is daily, weekly or custom, from 30 minutes to a year, in whole minutes. The first hand-over is one instant: the first participant goes on call then, and every later hand-over happens one cadence after the previous one. Its local time in the schedule’s zone is the hand-over time: a rotation that first hands over on a Monday at 09:00 hands over every Monday at 09:00 if it is weekly, every day at 09:00 if it is daily.

    Rotations run on the schedule’s wall clock, not on a UTC counter. Across a daylight-saving change the hand-over stays at 09:00 local on both sides, and the one shift that spans the change is an hour shorter or longer. On a day the clocks skip the hand-over time, the hand-over happens when they jump (02:30 becomes 03:00). On a day the time occurs twice, it happens at the first occurrence.

    An optional end date stops the rotation. A rotation without one runs indefinitely.

    Participants and weighted turns

    A rotation has from 1 to 50 participants, in hand-over order. A participant can be:

    TypeIn the consoleMeaning
    userMemberA member of the team (an Observer cannot be on call).
    teamWhole teamEvery member of a team of the organization is on call for that turn.
    escalationEscalation policyA policy of the same team stands in for that turn: a step that targets the schedule runs the policy instead.
    noneNobody (gap)Nobody is on call for that turn. Useful for a rotation that covers only part of the cycle.

    Each participant takes 1 to 100 turns in a row before the duty moves on. With everyone at 1 the rotation is a plain round robin. With Ana at 2 and Bob at 1, Ana takes two weeks of a weekly rotation and Bob one. The same person may appear more than once in the list.

    Active hours

    A rotation can be limited to windows of the week, up to 20 of them, each from a day and a time to a day and a time in the schedule’s zone, for example Monday 09:00 to Friday 18:00, or Friday 18:00 to Monday 09:00 for a weekend. Outside its windows the rotation covers nothing: that time is a gap unless another rotation of the schedule covers it. Windows that cross midnight are fine.

    Several rotations in one schedule

    A schedule holds up to 20 rotations, and every rotation that is active at an instant contributes its participant. Two rotations without active hours put two people on call at once, which is how a primary and a secondary share one schedule. A weekday rotation with business hours and a second rotation with the nights and the weekend split the week between two groups of people. There is no priority between rotations: all of them count.

    Overrides

    An override puts one member on call from a start to an end, for at most a year, replacing whoever the rotations would have put there. Overrides of one schedule may not overlap each other. The console lists the current and upcoming ones and marks the one that is on call now. Past overrides are kept in the calendar and the .ics file but not in the list.

    Team Owners, Managers and Responders can add an override, so a responder can cover a colleague without asking a manager. Deleting one takes an Owner or a Manager. A flow tool can create overrides too: the no-code guide drives a schedule from a shared Outlook calendar this way.

    Create an overrideJSON
    POST …/schedules/{scheduleId}/overrides
    {
      "start_time": "2026-11-14T18:00:00Z",
      "end_time": "2026-11-17T08:00:00Z",
      "user_id": "<Dana's user id>"
    }

    Who is on call

    The schedules list, the team overview, the dashboard and the mobile app all show who is on call right now and when the next hand-over is. The API answers the same question for any instant, past or future: GET …/schedules/{scheduleId}/who-is-on-call?at_time=2026-12-24T23:00:00Z returns the participants on call at that moment, each with the end of their shift, and the next hand-over. The escalation engine uses the same calculation when a step targets the schedule, so what the page shows is what gets paged.

    The calendar and the .ics export

    The calendar is a month view in the schedule’s zone, one colour per rotation, with overrides and gaps marked. Selecting a day lists its shifts. Download .ics writes the shifts as a calendar file, everyone’s or only yours, for the next 1, 3, 6 or 12 months, starting 24 hours ago and with overrides applied, to import into Google Calendar, Outlook or Apple Calendar. It is a one-time download rather than a live subscription: download it again after a change.

    The same file comes from GET …/schedules/{scheduleId}/ical?duration_months=3 with a personal API key, up to 12 months and 10,000 shifts. Events are in UTC and marked transparent, so they never block free/busy, and each rotation keeps a stable event identifier across downloads.

    The month calendar of a schedule in the IgniteOps console, one colour per rotation, with a weekend override highlighted
    The calendar of Platform Primary: Ana’s week, Dana covering a weekend as an override, and the Download .ics button.

    Using a schedule in policies and rules

    An escalation step or a routing rule can target on call now, next on call or previous on call on a schedule. "Next" is the person who takes over at the next hand-over, which gives you a secondary without a second schedule. A schedule that a policy step or a rule points at cannot be deleted while it is in use: the error names what uses it.

    Three patterns

    A weekly primary with a built-in secondary

    One weekly rotation of the whole team. Policy step 1 targets "on call now", step 2 targets "next on call" after two minutes, step 3 the team. The person who is up next week is this week’s backup.

    Business hours and out-of-hours in one schedule

    Rotation A, weekly, active Monday 09:00 to Friday 18:00, with the people who work days. Rotation B, daily, active Monday 18:00 to Tuesday 09:00 and so on through the week, plus Friday 18:00 to Monday 09:00, with the people who take nights and weekends. The example below is this schedule.

    Follow the sun

    Two or three rotations, each with active hours covering that office’s day in the schedule’s zone, each with its own people. Set the hand-over time to the start of the local working day. If a slot would otherwise be empty, add a Nobody (gap) participant or an escalation policy as the participant so that the gap is deliberate and visible on the calendar.

    Limits

    FreePro
    Schedules per team2Unlimited
    Rotations per schedule2020
    Participants per rotation5050
    Turns in a row per participant1 to 1001 to 100
    Active-hours windows per rotation2020
    Custom cadence30 minutes to 1 year30 minutes to 1 year
    Override lengthUp to 1 yearUp to 1 year
    .ics exportUp to 12 months, 10,000 shiftsThe same

    Through the API

    POST …/schedules creates a schedule with its rotations, PUT replaces the rotations (a rotation keeps its id, and its calendar events, when the request sends the id back), and the overrides have their own endpoints. A user participant must be a member of the team, a team a team of the organization and an escalation a policy of this team, else the request is refused with the rotation and the participant named.

    POST …/schedulesJSON
    {
      "name": "platform-primary",
      "timezone": "America/New_York",
      "rotations": [
        {
          "name": "Weekdays",
          "type": "weekly",
          "start_time": "2026-11-09T09:00:00-05:00",
          "participants": [
            { "type": "user", "id": "<Ana's user id>" },
            { "type": "user", "id": "<Bob's user id>" },
            { "type": "user", "id": "<Wei's user id>", "frequency": 2 }
          ],
          "time_restrictions": [
            { "start_day": "monday", "start_time": "09:00", "end_day": "friday", "end_time": "18:00" }
          ]
        },
        {
          "name": "Nights and weekends",
          "type": "daily",
          "start_time": "2026-11-09T18:00:00-05:00",
          "participants": [
            { "type": "user", "id": "<Dana's user id>" },
            { "type": "escalation", "id": "<Business hours policy id>" }
          ],
          "time_restrictions": [
            { "start_day": "monday", "start_time": "18:00", "end_day": "tuesday", "end_time": "09:00" },
            { "start_day": "friday", "start_time": "18:00", "end_day": "monday", "end_time": "09:00" }
          ]
        }
      ]
    }

    Checked against the product on November 8, 2026.