Any team running distributed engineering or IT operations eventually hits the same wall: PagerDuty incident management wasn't designed with time zones as a primary consideration. Native PagerDuty scheduling assumes a rotation is a rotation. It doesn't inherently know that the engineer in Singapore shouldn't be paged at 3 AM their time just because the schedule was built around a US-centric week.
This Tines 3B workflow gives team leads a simple web UI to build and reorder on-call rosters, then automatically syncs them to PagerDuty as time-zone-aware rotations, ensuring exactly one engineer is on call during their own local daytime hours at any given moment, with no manual schedule edits and no extra work when daylight saving time shifts.
The problem: Why follow-the-sun on-call scheduling is so hard to get right
For teams trying to run a true "follow-the-sun" model where on-call responsibility hands off around the globe so someone is always awake and alert, this creates real friction:
Manual time zone math. Team leads end up hand-calculating UTC offsets and manually overriding shifts every time daylight saving time shifts, someone joins the team, or a rotation order changes.
Hand-edited schedules drift from reality. Once an on-call scheduler is built by hand in the PagerDuty UI, it's rarely touched again carefully, leading to stale rotations, double-coverage gaps, or nobody on-call at all during a critical window.
Fragmented source of truth. Team rosters often live in spreadsheets, Slack threads, or someone's memory, disconnected from what's actually configured in the paging tool. When someone leaves the team or changes time zones, nothing forces an update.
Noisy, poorly targeted pagerduty notifications. Without zone-aware scheduling, engineers get paged outside their working hours, leading to alert fatigue, burnout, and, eventually, people silencing notifications altogether, which defeats the purpose of incident management in the first place.
Governance gaps. On-call tooling is often treated as "set and forget," with no clear record of who can edit schedules, why a rotation changed, or how to audit who was on call at a given moment.
A better process would let a team lead manage rotations declaratively - defining who's on the team and in what order - and have the actual PagerDuty schedule stay perfectly in sync automatically, with no manual edits, regardless of time zone or daylight saving changes.
The hands-on solution: a self-syncing on-call scheduler built with Tines 3B
This is exactly the kind of operational gap Tines 3B is built to close, not by replacing PagerDuty, but by sitting on top of it as an intelligent control layer that keeps schedules honest.
The relevant tool category here is incident management and paging platforms — PagerDuty is the example used, but the same pattern applies to any on-call scheduler with a shift-based scheduling API. The workflow talks to PagerDuty's user and Schedules APIs, maintains its own lightweight data store for team rosters, and renders a purpose-built web interface — no ticketing system, HRIS, or external database required.
This build is available as a ready-to-import workflow in the Tines 3B example gallery so you can get started right away. The gallery listing includes the exact natural-language prompt used to generate it — a detailed brief describing the desired UI, the sync logic, and the time zone rules — so practitioners can see precisely how the request was framed and adapt it to their own on-call scheduler, team structure, or paging tool of choice.
In this video, Danielle walks through how the workflow was built from the prompt and how she uses it in her day-to-day.
How the workflow works
The workflow has no cron job and no webhook trigger. It's entirely driven by a single-page web UI, which is the real entry point for team leads.
Load live data. When the page loads, it pulls the tenant's users (name, email, IANA time zone) directly from PagerDuty's API, alongside any teams already configured in local storage.
Build the roster. A team lead picks an existing team or creates a new one, then adds and reorders members to define the rotation order.
Save the roster. Saving upserts the team's name and ordered member list to the workflow's own storage.This is the internal source of truth, independent of whatever PagerDuty's "Teams" feature does or doesn't support on a given plan.
Sync on demand. Clicking "Save & sync" triggers a dedicated sync step that reconciles the roster against PagerDuty's shift-based Schedules API.
Smart, targeted updates. Rather than tearing down and rebuilding the whole schedule, the sync step only touches what changed: it creates a new rotation for a newly introduced time zone, deletes a rotation for a zone that's no longer represented, and - if a zone's member order changes - leaves historical shifts alone and inserts a successor shift effective the following Monday.
The key design decision: the workflow builds one rotation per distinct time zone represented on the roster, not one per person. Every rotation covers the same daytime business hours (e.g., 9–5) in its own zone, and all rotations share a single recurrence pattern and "epoch Monday" anchor. That shared anchor is what guarantees exactly one person is on call company-wide at any moment,and it's also why daylight saving transitions resolve themselves automatically, with no periodic recalculation needed.
What it connects
PagerDuty's Users API — to pull live name, email, and IANA time zone data per person
PagerDuty's shift-based Schedules API — to create, update, and delete rotations
A lightweight JSON-backed storage layer for team rosters, since not every plan or tool exposes a native "Teams" concept
A web UI rendered directly from the workflow, serving as the rotation builder, time zone preview, and team permalink hub
What it automates
Hand-calculating time zone offsets and business-hour windows
Manually rebuilding PagerDuty schedules every time a roster changes
Reconciling daylight saving time shifts across every affected rotation
Cross-referencing "who's actually on this team" against what's configured in the paging tool
How control is maintained
Every route in the UI is restricted to members of the workspace or space running the workflow — this is explicitly built as an internal tool, not a public-facing app. Past on-call history is never rewritten; changes only ever apply going forward from the next Monday, preserving an accurate audit trail of who was on call when. Each generated PagerDuty schedule's description includes a deep link back to the team's page in the rotation UI, so anyone auditing a schedule externally can trace it straight back to its source of truth. The workflow also respects platform limits (e.g., a cap on concurrent rotations per schedule), surfacing a natural constraint on how many distinct time zones one team's roster can span.
The outcome
Zero hand-edited schedules — every change flows through one UI and syncs automatically
One engineer on call at all times, globally — enforced structurally, not by convention
No daylight saving maintenance — rotations self-correct with no recomputation
Fewer off-hours PagerDuty notifications — engineers are only paged during their own local daytime
Full auditability — every schedule links back to its roster source of truth
Why build it with Tines 3B?
What stands out in this example isn't just the end result, it's how fast and adaptable the path to it is. The entire system, from UI to sync logic to time zone-aware recurrence rules, was generated from natural-language and is viewable in full in the example gallery. From there, teams can import the workflow directly into their own Explore tenant and use 3B's build interface to connect their own incident management platform, adjust business hours, change the rotation logic, or swap in a different on-call scheduler entirely, all through plain-language edits rather than custom code.
As requirements evolve — a new region added, a different paging tool adopted, business hours redefined — the workflow can be adapted the same way it was built: by describing the change. That same foundation extends naturally into related IT workflows, like automated incident escalation policies, on-call handoff notifications, or post-incident reporting synced back to a ticketing system.
If your team is wrestling with time zone chaos in PagerDuty, you don't need to write this from scratch. Import the on-call rotation manager directly from the Tines 3B example gallery, into a free Tines 3B Explore tenant, connect your own PagerDuty tenant, and customize it for your team in minutes — no prompt engineering required to get started.