Xitoring Document
Home
FAQ
Support
Register
Home
FAQ
Support
Register
  • Xitoring

    • Introduction
    • Release Notes
    • Xitoring Release Notes
    • Linux Xitogent Release Notes
    • Windows Xitogent Release Notes
    • Xitoring Mobile App Release Notes
    • Account Management
    • API Access & Automation
    • Team Management & Collaboration
    • Billing & Subscription Management
  • Getting Started

    • Getting Started with Xitoring
    • Workflows & Guides
    • Monitor Your First Server
    • Import / Migration
    • Migrate from UptimeRobot to Xitoring
    • Migrate from Pingdom to Xitoring
    • Migrate from Uptime.com to Xitoring
    • Migrate from BetterStack to Xitoring
  • Help & Support

    • FAQ & Troubleshooting
    • Glossary
  • Server Monitoring

    • Server Monitoring
    • Graphs
    • Live Statistics
    • Monitor Services
    • Auto-Triggers
  • Xitogent on Linux

    • Install Xitogent on Linux
    • Update Xitogent on Linux
    • Uninstall Xitogent on Linux
  • Xitogent on Windows

    • Install Xitogent on Windows
    • Uninstall Xitogent on Windows
    • Xitogent Service
    • Update Xitogent on Windows
    • Disk Performance (I/O)
  • Xitogent on Azure

    • Xitogent on Azure
    • Monitor Azure Linux VM
    • Monitor Azure Windows VM
  • Xitogent CLI

    • Xitogent CLI
    • Xitogent Pause/Unpause
    • Xitogent Status
    • Xitogent debug
    • Xitogent Diagnosis
    • Which data we collect
  • Xitoring CLI

    • Xitoring CLI
  • Uptime Monitoring

    • What is Uptime Monitoring
    • Monitoring Nodes (Geographic Locations)
    • What is Check
    • Auto-Discovery
    • Auto Fault Tolerance
    • Heartbeat Check
    • Ping Check
    • HTTP(S) Check
    • DNS Check
    • FTP Check
    • SMTP Check
    • IMAP Check
    • POP3 Check
    • TCP Check
    • UDP Check
    • Domain Expiry Check
  • SSL Monitoring

    • SSL Monitoring
  • Incidents

    • Incidents
    • Incident's Root Cause
    • Incidents Notification
    • Incident Notes
    • Acknowledge and Snooze Incidents
    • Resolving Incidents Manually
    • Incident Policy
  • On-Call

    • On-Call
    • On-Call Schedules
    • Escalation Policies
  • Maintenance Schedule

    • Maintenance Schedule
  • Email Reports

    • Email Reports
  • Integrations

    • Integrations
    • Apache Integration
    • CoreDNS Integration
    • CouchDB Integration
    • Disk Health Integration
    • Docker Integration
    • Dovecot Integration
    • Exim Integration
    • HAProxy Integration
    • IIS Integration
    • InfluxDB Integration
    • Kafka Integration
    • KeyDB Integration
    • LiteSpeed Integration
    • MongoDB Integration
    • MySQL Integration
    • Netstat Integration
    • Nginx Integration
    • OpenLiteSpeed Integration
    • OpenVPN Integration
    • PHP-FPM Integration
    • Postfix Integration
    • PostgreSQL Integration
    • RabbitMQ integration
    • Redis Integration
    • MS SQL Server Integration
    • Supervisor Integration
    • Varnish Integration
    • Wireguard Integration
  • Notifications

    • Notifications
    • Creating Notification Roles
    • Email Integration
    • Mobile Push Notifications
    • SMS Integration
    • Phone call Integration
    • Webhook Integration
    • Integration for Slack
    • Telegram Integration
    • WhatsApp Integration
    • Mattermost Integration
    • Discord Integration
    • Google Chat Integration
    • Microsoft Teams Integration
    • Microsoft Teams (Webhook)
    • Atlassian Opsgenie Integration
    • Jira Service Management
    • Splunk On-Call Integration
    • Pushover Integration
    • Pushbullet Integration
    • Gotify Integration
    • Ntfy Integration
    • Spike.sh Integration
    • PagerDuty Integration
    • Zapier Integration
    • AlertOps Integration
  • Status Page

    • Status page
  • 3rd Party Status Pages

    • Using 3rd party Status Pages
    • Atlassian Status Page Integration with Xitoring
    • Status.io Integration with Xitoring
    • Statuspal Integration with Xitoring
    • Instatus Integration with Xitoring
  • Dashboards

    • Main Dashboard
    • Custom Dashboards
  • Metrics

    • Metrics
  • MCP Server

    • Setup & Tool Reference

On-Call Schedules

An on-call schedule answers one question: who should be notified right now? Use it as a recipient in a notification role or an escalation policy, and the alert goes to whoever is on call when it is sent.

Schedules are included in the Business plans.

How Xitoring decides who is on call

Xitoring checks these in order and stops at the first match:

  1. An override covering that moment. If overrides overlap, the newest one wins.
  2. The layers, from the lowest position to the highest. The first layer with someone on duty at that moment wins. On a holiday, the first layer is skipped.
  3. Nobody. The schedule adds no recipient, and the role's other recipients are still notified.

A common setup is a follow-the-sun or weekend rotation at the top, with a weekly rotation underneath that covers every hour the top layer doesn't.

Time zone

Each schedule has one time zone, such as Europe/Berlin. Handoff times, restrictions and holidays are all read in it. Reminders are shown in each person's own time zone. Accounts start on UTC, so someone who has never set a time zone sees UTC.

Layers and rotations

Each layer has its own rotation:

SettingWhat it means
Position1 to 100. Lower positions are checked first. New layers go to the end
NameOptional
RotationDaily, Weekly, or Custom with a shift length of 1 to 720 hours
Handoff timeWhen one shift ends and the next starts, as HH:MM
Start dateThe first shift starts on this date at the handoff time. The layer is empty before that
MembersUp to 50 people, each at most once, in rotation order. Each must be the account owner or a team member
RestrictionsOptional. See below

Things to know:

  • The rotation is worked out from the start date. Adding, removing or reordering members can change who is on call straight away, and can change who has the upcoming shifts.
  • Daily and weekly shifts keep the same local handoff time across daylight saving changes. Custom shifts count real hours, so their local handoff time moves by an hour when the clocks change.

Restrictions

Restrictions limit a layer to certain hours, such as weekdays from 09:00 to 17:00. Outside them the layer has nobody on duty and Xitoring moves to the next layer.

Each layer can have up to 14 windows. A window has its days (1 is Monday, 7 is Sunday), a start time and an end time.

  • If the end is earlier than the start, the window runs past midnight into the next day. 22:00 to 06:00 on Friday ends on Saturday morning.
  • The rotation keeps counting during restricted hours, so a restriction doesn't delay anyone's turn.

Overrides

An override puts one person on call for a set time and beats every layer. Use it for sick days, swaps and handovers.

  • The person can be the account owner or any team member, whether or not they are in a layer.
  • The end must be after the start, and at most one year from now.
  • You can add a reason of up to 255 characters.
  • Deleting an override returns that time to the rotation.

Holidays

A holiday is a date in the schedule's time zone, with a name. For that whole date, the first layer (the lowest position) is skipped and the next layer takes over.

Use this with a primary rotation on top and a smaller holiday rotation underneath. On a schedule with only one layer, nobody is on call on a holiday unless there is an override. Overrides still apply on holidays.

Each date can be added once per schedule, and holidays don't repeat each year.

Cover requests

If you can't take your shift, ask your team to cover it instead of arranging an override yourself.

  1. Ask for cover for a time window. You must be on call for all of it, it must end in the future, and it can span at most 31 days. A start in the past is moved to now.
  2. Everyone else in the schedule's layers is notified by email, push notification and Slack direct message, if they use the Slack app.
  3. They answer under On-call in Xitoring. The first person to accept takes the shift: Xitoring creates an override for them, and you are notified.
  4. If everyone declines, the request closes and you are notified.

A few rules:

  • You can't have two open requests for overlapping time on a schedule.
  • Someone with their own open request for that time can't accept yours.
  • You can cancel your own request while it is open. So can anyone who can edit the schedule.
  • A request nobody answered expires at the end of its window.

Use a schedule as a recipient

Add a schedule as a recipient on a notification role or on an escalation policy step. Deleting a schedule removes it from both.

Calendar subscription

Subscribe to on-call shifts in any calendar app that reads iCal URLs.

FeedShows
My shiftsYour own shifts across all schedules in the account
One scheduleEveryone's shifts on that schedule

Create a feed to get its URL, then add it to your calendar:

  • Google Calendar: Other calendars → + → From URL.
  • Outlook: Add calendar → Subscribe from web.
  • Apple Calendar: File → New Calendar Subscription.

Good to know:

  • A feed covers the past 7 days and the next 60 days. Calendar apps refresh subscriptions on their own timing, so changes can take a while to show.
  • The URL works without logging in, so treat it like a password. Xitoring shows it only when it is created.
  • Creating a feed again replaces the URL and the old one stops working. You can also revoke a feed.
  • A feed stops working if you leave the account, the schedule is deleted, or the account no longer has a Business plan.

Shift reminders

Xitoring sends each person a reminder by email and push notification:

  • Before a shift starts. 30 minutes before by default. You can set this from 0 to 1440 minutes (24 hours), and it applies to all your schedules. 0 turns this reminder off.
  • When a shift has ended. This one is always sent.

Back-to-back shifts for the same person count as one shift, even across layers.

API

Authenticate with an API key. All paths start with /api/v2/oncall.

RequestWhat it does
GET /nowWho is on call now, per schedule
GET /schedulesList schedules
POST /schedulesCreate a schedule: name, timezone, optional description
GET /schedules/{id}Layers, overrides, holidays and who is on call
PUT /schedules/{id}Update a schedule
DELETE /schedules/{id}Delete a schedule
GET /schedules/{id}/shiftsFinal shift timeline. from and to default to the next 7 days, and can span at most 93 days. A shift with no member means nobody is on call
POST /schedules/{id}/layersAdd a layer
PUT /schedules/{id}/layers/{layerId}Update a layer. Sending members replaces the list
DELETE /schedules/{id}/layers/{layerId}Delete a layer
POST /schedules/{id}/overridesAdd an override: member, starts_at, ends_at, optional reason
DELETE /schedules/{id}/overrides/{overrideId}Delete an override
POST /schedules/{id}/holidaysAdd a holiday: date, name
DELETE /schedules/{id}/holidays/{holidayId}Delete a holiday
GET /cover-requestsList cover requests. status is open (default) or all. Optional schedule_id
POST /schedules/{id}/cover-requestsAsk for cover: starts_at, ends_at, optional reason
POST /cover-requests/{id}/acceptAccept a cover request
POST /cover-requests/{id}/declineDecline a cover request
DELETE /cover-requests/{id}Cancel a cover request
POST /schedules/{id}/calendar-feedCreate a schedule feed and return its URL
DELETE /schedules/{id}/calendar-feedRevoke your schedule feed
POST /my-calendar-feedCreate your personal feed and return its URL
DELETE /my-calendar-feedRevoke your personal feed
GET /my-settingsYour reminder setting and feeds
PUT /my-settingsSet reminder_minutes

Send times in ISO 8601 with an offset, such as 2026-11-09T18:00:00+01:00. The API reads a time without an offset as UTC.

A layer looks like this:

{
  "position": 1,
  "name": "Business hours",
  "rotation": "weekly",
  "handoff_time": "09:00",
  "starts_on": "2026-11-09",
  "restrictions": [
    {"days": [1, 2, 3, 4, 5], "start": "09:00", "end": "17:00"}
  ],
  "members": [
    {"type": "client", "id": 3},
    {"type": "contact", "id": 7}
  ]
}

For a custom rotation, use "rotation": "custom" with custom_shift_hours. In members, client is the account owner and contact is a team member.

From an AI assistant

The MCP server has list_on_call_schedules, get_on_call_schedule, who_is_on_call and create_on_call_override. Unlike the API, these tools read a time without an offset in the schedule's time zone.

Last Updated: 11/9/26, 8:51 PM
Prev
On-Call
Next
Escalation Policies