How a modernized IT Ops team cut alert noise, slashed ITSM costs by 37%, and built a fully connected Ops platform that traces change and reclaims on-call sanity.
The learnings in this blog post are based on the session, “From alert noise to action: How 24 Hour Fitness modernized IT Ops with Jira Service Management”, presented at Atlassian’s Team ’26 conference. You can check out this session and others on demand.
Across hundreds of fitness clubs in the United States, the 24 Hour Fitness IT Ops team is responsible for keeping critical systems running for members, employees, and club operations. Their work goes beyond building applications; the team also owns the day-to-day reliability, incident response, and operational processes that keep the business moving.
Before Jira Service Management, IT operations at 24 Hour Fitness were an uphill battle:
- No automated on-call system. They had a homebrewed, static on-call schedule with no overrides, nothing dynamic. A human had to read alert emails coming from monitoring systems and manually figure out who to wake up at 2 a.m.
- Constant context switching. Once an engineer got the call, they had to log in, create an incident ticket, flip over to monitoring and telemetry tools, then flip back to the ticket to take notes.
- Disconnected data. Change records and incident records lived in different systems for months, so teams couldn’t reliably connect an outage to the change that caused it, or see downstream impact across locations.
- No change to incident traceability. If a deployment caused an incident (or dozens of incidents across multiple clubs), there was no way to trace it back. People made changes under the table because the old system was so onerous to work with.
Top 4 issues for IT Ops teams not on Jira Service Management
- Too many alerts — a flood of notifications, many with zero actionable value
- Disconnected Dev and Ops tools — teams working across separate systems, without shared context for changes and incidents, or a single platform to keep everyone in sync
- Manual on-call routing — a human reading alert emails in the middle of the night and deciding who to page using only the options they’ve saved
- Expensive, slow-to-change legacy platforms — legacy ITSM suites are complex and costly to deploy, maintain, and update
Revolutionizing IT Ops at 24 Hour Fitness with Jira Service Management
Fortunately, 24 Hour Fitness was already leveraging Jira and Confluence, so when Principal Engineer Rick Westbrock decided enough was enough, he turned to Jira Service Management to modernize their ITSM from their legacy solution.
Alert grouping
Gaining access to the alerts feature in Jira Service Management was a big deal in itself. But the real value came from alert grouping. If Westbrock gets woken up in the middle of the night and logs in to see a wall of alerts, it is a lot easier to mentally process three alert groups than 35 individual alerts. He can expand any group to see its specific alerts, but the grouping instantly reduces cognitive load.
It’s a lot easier to process mentally if I’ve got like three alert groups rather than 35 individual alerts.”
Rick Westbrock, Prinicpal Engineer, 24 Hour Fitness
Signal vs. noise classification
Why would you ever have noise in your alert stream? Westbrock explained the reality: sometimes it is more challenging to fine-tune a monitoring system to send only actionable alerts into Jira Service Management. Many Ops teams found it better to create too many alerts and then sort through them. Jira Service Management lets engineers mark individual alerts as signal (pay attention) or noise (ignore), and that feedback actively trains the AI model to make better triage decisions in the future.
Automated on-call routing and escalation
This was a big one for Westbrock, especially since he is on call. Automated on-call removes the human from the routing loop, so there are no more mistakes like calling the wrong person. Westbrock’s team pioneered heavy use of escalation policies:
- An alert fires a notification through the Jira Mobile app. Even if Westbrock is sound asleep, the persistent notification keeps hammering his phone until he picks up.
- If he acknowledges it, great. Two seconds and done.
- If he somehow misses it, it notifies him again ten minutes later.
- If he still does not respond (phone in the car, battery dead), ten minutes after that, his manager gets woken up.
I am not sure which is worse, Westbrock joked. A grumpy manager or a grumpy household at three in the morning.
The key point: the chance that both people miss the alert is extremely small.
Notification policies for quality of life
Some critical flows break at 2 a.m., but don’t need to be fixed then. They just need to be fixed the same day, including weekends and holidays. Westbrock’s team uses notification policies to delay those alerts. A 3 a.m. break gets held until 7 a.m., when the engineer is already online. Something that breaks on Friday night gets held until Monday morning. People actually get to relax on weekends.
One-click incident creation and cross-linking
When Westbrock receives an alert on his mobile device, he can log in, open the alert, and tap a single button to create an incident. That single click creates the incident and automatically links it back to the alert. No more switching from the alerts console to a Jira project, creating a ticket, and manually linking it.
Most of their Ops teams don’t actually work on Jira Service Management service projects. They work in Jira Software projects. The Create Incident button works for both Jira Service Management incidents and Jira Software work items. Westbrock’s team even built automation rules that look at the priority and summary of an incoming alert, walk through matching policies, and automatically create the appropriate work item.
Change request to incident linking
A product owner or developer can open a change request and view all linked incidents. A typical scenario at 24 Hour Fitness: one parent incident with dozens of child incidents, because if 15 clubs experience the same problem and all 15 call the service desk, that is 15 individual incidents tied to one root cause.
Conversely, a service desk agent looking at an incident can immediately see that it was caused by a specific change. Developers can look at that traceability and improve their deployment plans for next time. Maybe they were missing an artifact. Maybe their rollback plan was incomplete. The data is right there now.
The measurable results of implementing Jira Service Management at 24 Hour Fitness
- 37% savings on their annual ITSM tooling budget
- 20% more changes captured because the old system was so painful that people would skip the change request process entirely. Now they actually log what they are doing.
- 100% change to incident traceability with changes, incidents, and deploy tickets all linked together
What’s next for 24 Hour Fitness
With Jira Service Management already delivering measurable results – 37% budget savings, full change-to-incident traceability, and a dramatically better on-call experience – Westbrock is not slowing down. In fact, he identifies three initiatives on 24 Hour Fitness’s near-term roadmap, each designed to push its operations further toward AI-assisted, fully connected IT.
1. Dynatrace integration with Rovo Ops
Today, when an alert fires, an engineer has to switch to the Dynatrace UI and manually navigate through dashboards and traces to find the root cause. Not every engineer is skilled at that navigation. With the Dynatrace MCP integration, they will be able to ask Rovo to review the Dynatrace data and identify the probable cause. Westbrock expects a meaningful improvement in time-to-resolution.
It’s really going to help engineers to be able to ask Rovo, go look at the Dynatrace data and tell me what probably caused this, so that’s going to be an improved time resolution for sure.”
Rick Westbrock, Prinicpal Engineer, 24 Hour Fitness
2. Dedicated Slack channels for incident troubleshooting
A week before the presentation, Westbrock’s team piloted dedicated Slack channels per incident. Previously, every outage funneled into a single generic channel, creating an endless thread that Rovo couldn’t parse and that late joiners couldn’t follow.
Now, from an incident ticket in Jira Service Management, a single click creates a Slack channel named after the ticket number and summary. When the incident closes, Rovo drafts the post‑incident review from that focused conversation, faster and higher quality.
Late joiners also get instant context by entering the channel and asking Rovo to summarize what’s happened so far.
“If somebody’s late joining the outage call, they can jump in the dedicated Slack channel and ask Rovo to summarize and it’ll just… give them a quick synopsis of what’s happened already that they missed to get them up to speed.”
Rick Westbrock, Prinicpal Engineer, 24 Hour Fitness
3. CMDB migration to Atlassian Assets
24 Hour Fitness currently runs a homebrewed CMDB that tracks VMs, network infrastructure, and related assets. It is a manually maintained, on-premises database. They are designing what that will look like in Atlassian Assets.
Westbrock highlighted several benefits they are looking forward to:
- Visual representation of how different objects link to each other, similar in spirit to the Teamwork Graph
- Data Manager integration, which Westbrock has been waiting for. The Data Manager can pull inventory from multiple systems, normalize the data, and automatically push it into Assets. No more humans manually updating the CMDB.
- API access so that all of their operations teams (who, as Westbrock noted, now consider themselves software developers with domain expertise in ops) can write scripts that query, update, and manage the CMDB programmatically
All of the Ops teams are now going to be able to write scripts that can query the CMDB and assets… all programmatically so less hands-on work for humans.”
Rick Westbrock, Prinicpal Engineer, 24 Hour Fitness
Three takeaways to walk away with
- Supercharge incident resolution by connecting your observability stack to Jira Service Management and Rovo Ops
- The Teamwork Graph is the differentiator. Its context, combined with third-party tool data, makes your AI agent dramatically more powerful than a standalone LLM
- Leverage Rovo to enhance signal-to-noise classification and alert grouping so that the 3 a.m. false alarms stop happening
Service Collection and the Teamwork Graph powering AI-native IT operations
At the platform level, these results are powered by Service Collection: a combination of Jira Service Management, Customer Service Management, Assets, and Rovo Ops.
The three main goals behind Service Collection include:
- Elevate support for every team, not just IT
- Accelerate innovation by connecting Dev, Ops, and Support
- Deliver value fast without the cost and complexity of legacy platforms
The high-level architecture connects five operational workflows: deploying changes, monitoring and alerting, diagnosing and responding, resolving and recovering, and running the post-incident review (PIR) learning loop. These workflows sit on top of platform capabilities like the service catalog (Assets), automations and orchestration, and stakeholder communications.
All of it connects to the Atlassian Teamwork Graph, a unified intelligence layer that connects people, the work they do, the projects they work on, and the knowledge the company has (stored in Confluence and beyond). It is not limited to Atlassian data, as there are over 100 connectors to third-party tools.
Why does this matter for AI?
A generic AI model that receives a CPU spiking alert can only say, “Your CPU is spiking.”
But AI connected to the Teamwork Graph can say: “The CPU is spiking because there was a deployment on this service. Sarah deployed it through this Jira ticket, and I have already paged her to come help mitigate.”
3 key AI Ops features in Service Collection
Atlassian AIOps adds AI context from observability tools, alert history, and the Teamwork Graph to help teams resolve incidents faster with less on-call noise.
- Third-party observability integrations: Connect tools like Dynatrace or New Relic so responders can ask AI for root-cause summaries, next steps, and related knowledge without switching dashboards.
- Signal vs. noise classification: Alerts are labeled signal, noise, or unclassified with plain-English reasoning, and engineer feedback improves future triage.
- Custom alert grouping: Similar alerts can be grouped by time window, service, tags, source, or priority, turning many notifications into a few actionable clusters.
The broader AI Ops impact
Across their customer base, Atlassian is seeing:
- 75% reduction in alert noise. Three out of every four alerts that would have woken someone up or interrupted their flow are now filtered out.
- Approximately one hour saved per incident. That is critical engineering time returned to building, coding, and shipping.
- Six times faster PIR creation. A task that used to take a full day of writing can now be completed in a fraction of the time.
Build your connected Ops platform
24 Hour Fitness saw tangible results by unifying alerting, incidents, changes, and knowledge on a single platform. Service Collection brings Jira Service Management, Assets, Customer Service Management, and Rovo agents together so teams can cut noise, resolve faster, and learn with every incident.
Ready to see what this could look like in your environment? Explore Service Collection to connect your tools, your teams, and your data, then turn operations into a continuously improving engine.
