Time-zone-aware daytime on-call rotation manager for PagerDuty
Build a workflow that lets a team lead build a follow-the-sun on-call schedule and keep it synced to a paging/on-call tool — PagerDuty, or your team's on-call tool of choice — without ever hand-editing schedules there. There is no cron or webhook trigger — everything is driven from a single-page web UI. The UI is the entry point: it loads the tenant's users (name, email, IANA time zone) from the paging tool's API, and the teams already configured from local storage. A user picks or creates a team, builds its rotation order by adding people and reordering them, and saves — this upserts the team's roster (name + ordered member ids) to storage. Clicking "Save & sync" triggers a sync step that talks to the paging tool's shift-based Schedules API to create or update that team's real on-call schedule. Design the sync around one rotation per distinct time zone represented in the roster, not one per member — each rotation covers weekday business hours (e.g. 09:00–17:00) in its own zone, and every rotation shares the same recurrence and a single "epoch Monday" anchor so that in any given week exactly one rotation resolves to a real person and every other position is empty. This is what makes "only one person on call company-wide at a time" hold without manual overrides, and it makes daylight-saving transitions handle themselves with no periodic recomputation. When a roster is edited, only touch what changed: create a rotation for a newly-introduced time zone, delete a rotation whose zone was removed, and — when a zone's member order changes — leave past history alone and insert a successor event effective the following Monday. Note the paging tool's plan/API may limit how many concurrent rotations a schedule can hold (e.g. 10), which caps how many distinct time zones one team's roster can span. If the paging tool doesn't have a "Teams" concept enabled on your plan, keep team membership as an internal artifact in your own storage rather than trying to read it from the external tool — but still pull each person's live profile data (name, email, time zone) from that tool. Also set each generated schedule's description to a deep link back to that team's page in your rotation UI, so anyone viewing the schedule externally can jump straight back to the source of truth. Structure it as: (1) a step exposing an endpoint that lists all users from the paging connector, (2) a storage step exposing endpoints to list/create/update/delete team rosters (persisted to a small JSON store), (3) a sync step exposing an endpoint that takes a team id and reconciles that team's rotations against the paging tool's API, and (4) a webpage step rendering the actual rotation-builder UI (team picker/creator, member search-and-reorder, a live preview of which time zones become which rotations and who's in each, and a "Save & sync" action). Give the UI a stable per-team permalink so a link can point directly at one team's schedule. Keep every route restricted to members of your workspace/space — this is an internal tool, not public-facing. Tools used: PagerDuty
What this prompt builds
This workflow builds a web UI that generates and syncs follow-the-sun on-call schedules to PagerDuty, ensuring each engineer is on call only during their local business hours (e. g. 9–5) rather than being locked to a single time zone.
The problem
PagerDuty doesn't natively support daytime on-call schedules that follow each engineer's local time zone, forcing global teams to align rotations to a single geography — which means engineers in other regions get paged at inconvenient hours or have to rely on manual workarounds to block alerts. This workflow solves that by letting team leads build and automatically sync follow-the-sun on-call schedules through a simple web UI: it generates one rotation per distinct time zone, anchored so that each engineer is on call only during their own local business hours (e.g., 9–5), while ensuring exactly one person is on call company-wide at any given moment. Changes to the roster — adding people, reordering rotations, or introducing new time zones — sync directly to PagerDuty's shift-based API with no manual schedule editing, and daylight saving transitions handle themselves automatically.
Solution and impact
Teams get a single-page rotation builder that pulls live user profiles from PagerDuty and stores roster configurations locally, then syncs them to real on-call schedules without ever hand-editing shifts in the external tool. By anchoring all rotations to a shared recurrence and creating one rotation per time zone (not per person), the workflow ensures only one engineer is on call at a time across the entire company, respects everyone's local working hours, and adapts to daylight saving changes with no manual intervention. The result is fairer, more sustainable on-call coverage for distributed teams and fewer middle-of-the-night pages for engineers outside the company's primary time zone.