Operations | Monitoring | ITSM | DevOps | Cloud

We’ll be rolling out new Slack capabilities to eliminate more manual toil from your incident workflow: click once to promote any alert to an incident, get dedicated channels created automatically, page responders without leaving Slack, and manage all your settings in one place. This is part of our path to autonomous operations: reducing toil, protecting your capacity, and letting you stay in flow. If you’re only using PagerDuty for on-call scheduling, you’re missing the full picture.

AI promise and AI capabilities often diverge, with developers often reporting much faster code production, but not enough change in how incidents are handled. When the rate of change is faster than ever, but the rate of recovery from incidents isn’t moving, developers wind up stuck in firefighting mode. And, when these systems fail, it’s costly. According to PagerDuty’s State of AI-First Operations, over a third of surveyed companies report losing $500K per hour of downtime.

This blog post is part of PagerDuty’s ongoing series on how we’re helping customers navigate their journey towards autonomous operations. Read on to learn about how PagerDuty’s Shift-Based Schedules (planned GA in May) builds towards this vision. PagerDuty has long been the gold standard for on-call management, helping thousands of teams build the foundations of digital reliability.

Earlier this year at our H1 2026 launch, we announced PagerDuty’s vision for autonomous operations: a future where AI agents learn from every incident, prevent failures before they happen, and progressively automate so teams can focus on innovation instead of firefighting.

Where do your teams go during a critical incident? For distributed teams, that war room is a channel in Slack or Microsoft Teams. The question is: are you creating a dedicated space for each incident, or are responders scrambling across DMs, email threads, and general channels trying to piece together what happened? The answer matters. Using dedicated incident channels has become the industry standard for high-performing incident response teams.

Recurring incidents are a symptom of a broken process. Your teams are working hard to get services back online, but constantly battling the same problems is frustrating and not a sustainable approach. What’s reflected here is not a failure in engineering abilities, but a deficiency in the learning that should follow an incident. When incident analysis focuses on finding a single person or team to blame, it creates a culture of fear.