After a decade of reliable on-call coverage, the demands of modern operations pushed us to reimagine what PagerDuty Schedules could be. Here’s the behind-the-scenes journey from rethinking and tearing that scheduling system down to its core, then rebuilding it as a shift-based, iCalendar-compliant service, and using data and agents to get every customer there safely.

Reengineering Schedules for Modern Operations

Schedules are one of the foundational domain models in PagerDuty, and layer-based schedules, configured with one or more layers where users rotate daily or weekly, were built for a simpler world of operations. As teams moved from reactive firefighting toward automated remediation, and the systems underneath them grew more distributed and complex, they outgrew what a simple daily or weekly recurrence could support.

The Schedules codebase lived entirely within the monolith, built around three core functional areas: configuration, compute, and rotation layers (including the resulting Final Layer that determines who’s on-call). Schedules configuration lived in custom, proprietary recurrence logic. Schedules compute was tangled directly into the monolith’s ActiveRecord callbacks. And rotation layers (the series of shifts a user actually sees) were a by-product of running that compute algorithm against the recurring config. These three functional areas were so tightly coupled that even a simple schedule edit became a complex transaction: open a database transaction, run the computation inside it, then roll it back just to return mock shifts for the user to preview before deciding whether to save the changes.

That complexity cut both ways. It made it hard for engineers to navigate the existing system, let alone extend it, and customers felt the limits directly. The workaround inevitably led to more workarounds. Overrides stacked on overrides, and schedule management grew more cumbersome for the very users they were meant to help.

A complete teardown and replacement of our layer-based scheduling system was a high-stakes bet: we couldn’t rip out Schedules and replace it in one move without risking incorrect pages, dropped incidents, and delayed responses, the exact thing PagerDuty exists to prevent. So instead, we phased it, shipping incremental value while re-engineering the foundational architecture from the ground up, in three moves:

1. Tackle the legacy – refactor schedules compute, isolate it, then move it out of the monolith entirely
2. Rebuild the core – elevate shifts as first-class domain objects, and build an agentic foundation for better interoperability across our growing agent ecosystem
3. Optimize for the future – balance coverage across human and virtual responders as on-call itself becomes increasingly autonomous

Phase 1: Fixing the foundation before touching the feature

Moving the foundation out of the monolith shipped zero new customer-facing features. However, it brought reliability and made every following step possible.

• Scale: handling 2x today’s volume with headroom to 10x, on 30% fewer resources
• Accuracy: hit 99.95% match threshold; schedules that failed to compute dropped from 0.42% to 0.03% (a 93% drop)
• Velocity: 55% faster deploys, 11% faster database queries, 2x developer productivity with modernized tech stack
• Tech Debt: fixed bugs open since 2020; got rid of the fake-create-then-rollback preview complexity for good

Architecture: built with the legacy in mind

Every engineering discussion about rearchitecting Schedules circled back to the same non-negotiable: reliability isn’t a trade-off. The way out was two-fold:

• A single entry point, a Facade that orchestrates all the requests from calling systems to the schedules domain
• An unchanged Final Layer, the one thing nearly every dependency on a schedule actually asks: “who is on call at time X?”

As long as we have an Orchestration Layer that facilitates API versioning and a Final Layer that stays intact in the monolith, we can change everything about schedules without impacting a single consumer (e.g: escalation policies, teams) and everything else built on top of it.

Innovation: an AI-First mindset

While we were re-architecting the foundation, we spent multiple hack weeks running at the same pain points from an AI-First angle, looking for ways to leapfrog constraints architecture alone wouldn’t solve. We tried quick workarounds that solved immediate pain but didn’t scale, then a series of bigger experiments like a standalone conflict-detection system, AI that generated schedules, and solvers that optimized coverage mathematically. Most of these didn’t ship as-is, but each narrowed in on what mattered: coverage that’s both precise and easy to work with.

One idea quickly went from a hack-week project to reality. It became the basis for Shift Agent, one of the first agents at PagerDuty, proactively flagging on-call conflicts and recommending coverage before anyone has to go looking for it. The rest of the hack ideas weren’t wasted effort either; they were the R&D that made the shift-based model, and the agent sitting on top of it, possible.

Phase 2: Rebuild schedules as a calendar, not a config language

With the architecture guardrails from Phase 1 in place, we could finally reassess not just how schedules should be computed, but what a schedule fundamentally is.

Three ideas anchor the new design: give shifts their own identity, let a standard handle when coverage is needed, and leave ourselves free to get creative with who covers the shift.

• Elevate shifts as a first-class domain object. Introduce a native shift object within the schedules domain, so a shift is no longer a byproduct computed on the fly from a schedule’s configuration but a durable, addressable entity in its own right.

• Leverage existing standards for defining when coverage is needed. Replace proprietary recurrence definitions with iCalendar (RFC 5545), a spec that global calendar tools already leverage, and that LLMs already understand natively. Simple presets, custom rules, and raw iCalendar definitions all map onto the same standard, so we consistently generate valid recurrence rules across a wide range of use cases.

• Determine who covers the shift with flexible shift assignment strategies. Flexible shift-assignment types (rotate vs. all-members-on-call), a purpose-built UI with quick-start templates that mimic common rotation patterns (weekly handoff, workweek/weekend, follow-the-sun, custom), and even natively unassigned shifts make it easier for teams to model coverage the way they actually work rather than using workarounds.

API Versioning: the price of a safe upgrade

We’re just as deliberate about the API surface as we are about everything underneath it. Rather than break existing integrations, we built a new, versioned set of schedules APIs alongside the current ones, a safety net that cleanly separates layer-based behavior from the rearchitected shift-based model.

Every change shipped as a graduated, intentional rollout as part of our broader release strategy, all the way from internal preview and early access to general availability and an upcoming phased upgrade period. This way, old and new schedules can run side by side the whole way through. Along the way, we’ve partnered directly with customers to fold their feedback and real-world use cases into the new model.

The result: every account has a working API no matter which model their schedules are on, and every customer can move from layer-based to shift-based schedules automatically or manually on their own timeline to take advantage of this new scheduling experience. Once upgraded, teams benefit from reduced manual toil around on-call management and the architectural flexibility modern operations require, freeing them to focus on what matters: keeping systems highly available.

Upgrade: Let the data decide how to move forward

Change management at scale is hard, and rolling out a change that touches millions of users is no exception. A traditional change-impact matrix (how many users are affected, how disruptive the change is) is a reasonable starting point for broadly categorizing accounts into a gradual rollout. But it assumes a uniformity that doesn’t exist here: not every schedule within an account is even set up the same way, let alone every account.

Upgrading a schedule is seamless only if we can get every existing customer onto the new model safely. That’s a data problem as much as an engineering one, so we leveraged a data-driven strategy. For every one of PagerDuty’s active schedules, three questions had to be answered:

• Is there a lossless representation between the layer-based and shift-based model?
• Is it safe to upgrade automatically, or does a human need to review it?
• How do we do this at scale, across all of them while giving end users necessary input for decision-making?

The answer: schedules aren’t snowflakes. They cluster into a handful of recognizable shapes. Most are simple and safe to auto-upgrade; a small, genuinely complex tail is where a human (or human-like intelligence) needs to stay in the loop so the safe majority never needs a person at all.

Every existing schedule has an equivalent, lossless representation in the new model, and that part was never in question. What varies is how many ways there are to configure it:

• 60% of schedules map to the new model with no ambiguity and can be upgraded automatically, without human intervention.

• 40% have more than one valid way to configure the same recurring pattern. So those go through a user-initiated (optionally agent-assisted) upgrade flow with human-in-the-loop approval, rather than a fully automated one.

The underlying philosophy was simple: human heuristics get lost in translation between teams, but data doesn’t. So instead of assuming what to build, we started by looking at what the data actually was, clustering schedules by their real characteristics rather than by hunches about what customers were probably doing. Once those clusters emerged, we layered human-understandable labels on top of them, and used the resulting risk stratification to put effort exactly where it was needed.

A self-serve upgrade UI will roll out for teams to review all their schedules, check upgrade eligibility based on each schedule’s pattern and complexity, and preview the change before upgrading. For schedules with more than one valid configuration, the only lift required is to review the proposed mapping and save it. The analysis itself will be done for them, optionally by an agent that evaluates the current configuration and proposes the upgrade path tailored to that schedule.

Phase 3: Optimize schedules to forge a path towards autonomous operations

The last piece of evolution turns passive rotations into schedules that manage themselves under a set of constraints and escalation policies that can page a virtual responder as readily as a human one.

Shift Agent was the first step in building an agentic framework into PagerDuty schedules and calendar integrations. It proactively flags conflicts like PTO overlapping an on-call shift and offers to find coverage. That same agentic AI framework extends to assisting users with upgrading their complex schedules to shift-based.

Shift Agent operates at the schedules domain level, deciding who’s covering a given shift. One layer up, we have escalation policies with incident assignment strategies ensuring the right person is paged for an incident. This is where the SRE Agent can be configured to act as a Virtual Responder.

SRE Agent deeply integrates into the team’s escalation policies directly, acting as the first line of defense by connecting to event intelligence, on-call data, and service context to summarize an incident, identify root causes, and recommend next steps for a human to review. It’s the same underlying model, flexible, standards-based coverage in the moment an incident actually happens, not just as a shift hand-off.

In the future, we plan on taking agentic scheduling further, so coverage stays fair without anyone rebalancing it manually, shifts swap with awareness of context around them, and users can opt-in for automatic resolution of upcoming conflicts.

What comes after “who’s on call?”

For as long as Schedules have existed, they’ve answered one question: which human do we page? Everything along our journey – the schedules compute refactor, the iCalendar standard, shift-based domain model, layer-based schedules upgrade, even Shift Agent was three years of rebuilding under that question without changing what it was for.

That part is starting to change. Once a virtual responder can sit on the same escalation policy as an on-call engineer, “who’s on call” stops meaning “which person” and starts meaning “a combination of human and agent responders who have this covered right now.” We built the foundation to answer that question no matter how it got computed.

That’s what a re-architected foundation gets us: an intuitive calendar, native integrations, agentic capabilities, and flexibility that meets every team where they are.

About the authors

Ken Choate is a Senior Software Engineer on PagerDuty’s Mobilization team, where he has worked on evolving schedules since joining the company more than 3 years ago. With over a decade of experience building full-stack applications, his work is currently focused on building the next stage of AI-optimized scheduling and incident mobilization. Ken holds a B.S. degree in Computer Science from the University of Houston, with a focus on Software Engineering.

Ulas Keles is a Software Engineer Tech Lead at PagerDuty, where he builds and leads engineering for scheduling and mobilization software systems. He specializes in turning ambiguous, high-stakes problems into production-grade systems, working at the intersection of distributed systems, AI-powered products, and large-scale organizational coordination. His current focus is making incident management AI-native. Ulas holds an M.S. degree from the University of Illinois Chicago, where he worked on ontology alignment and semantic web research.

Ze Yuan Li is a Senior Machine Learning Engineer on PagerDuty’s Mobilization team, where he applies AI to modernize scheduling and responder mobilization. He’s currently leading the layer-based to shift-based schedule upgrade, building the experience to make the upgrade seamless for customers. He holds an M.S. from Cornell University, where his research focused on synthetic data generation for mental health diagnostics.

Madhuri Jakkaraju is an engineering leader with experience driving technological transformation and innovation. As a Senior Manager of Software Engineering, she leads the engineering strategy for the mobilization domain. She and her team have filed three patents for their innovative work advancing Agentic AI and LLM capabilities for differentiated and intelligent products.