Consolidating incident and change signals in cloud operations
A European technology group runs more than 320 cloud services; hundreds of incidents and changes arise every day, and the signals are scattered.
- Technology
- IT Operations
Key metric
Processing time per incident
4024min
Average processing time per incident in IT operations
At a glance
Starting point
The group runs several cloud platforms with more than 320 services in total for internal products and customer solutions. IT operations consists of 4 platform teams and a central operations center with around 25 full-time staff combined. On average, 280 incidents and 180 changes arise per working day, spread across the ticketing system, monitoring, deployment pipelines and chat channels. An incident takes 40 minutes to handle on average, and a change including documentation around 60 minutes. On-call duty is driven by monitoring and tickets, but dependencies between services and parallel changes exist only in scattered documents and people's heads.
- 320
- cloud services
- 460
- incidents and changes/day
The challenge
Day to day, the teams have to decide which incidents to handle first, which changes should be postponed and when additional specialists need to be brought in. Monitoring generates hundreds of alarms every day and tickets contain free-text descriptions, while planned changes are documented in deployment tools and wikis. These signals are brought together manually by experienced employees who piece the information together from several systems. Critical knock-on effects, such as an incident in a core service during a parallel change, are often recognized late. This leads to longer outages, unplanned night shifts and a lot of coordination between platform teams, product development and business units.
Typical symptoms in the organization
Why this remained unsolved
Those responsible had seen the problem for years but prioritized other platform expansion projects. A classic IT project seemed too big because several systems and teams were involved, yet the effort for manual coordination was too high to ignore. Attempts with additional dashboards had no effect, as they only aggregated technical metrics and made no connection to tickets, changes and business criticality. Without a solution that understands signals from different sources, brings them together and makes concrete suggestions for action, coordination remained heavily dependent on individuals.
Our solution
An agentic workflow was introduced that continuously bundles signals from monitoring, the ticketing system, deployment pipelines and chat channels. The system maps incidents and changes to the affected services, assesses criticality based on defined business impact classes and detects conflicts, such as parallel changes to a core service that is already disrupted. For on-call teams, the workflow provides a consolidated view of current incidents, planned interventions and known dependencies. It generates prioritization suggestions, recommends escalations to specialist teams and helps document decisions for audits. The platform teams keep their existing tools but gain an overarching control layer that structures context and next steps.
Where generative AI comes in
Generative AI analyzes free text in tickets and chats, summarizes symptoms and impact, and maps them to services and business units. It recognizes patterns in incidents and changes, formulates prioritized suggestions for action and creates clear summaries for handovers and audits.
- Connection of monitoring, the ticketing system, deployment pipelines and chat channels to a central workflow that standardizes signals.
- Configurable assessment logic for business impact, service criticality and dependencies that automatically prioritizes incidents and changes.
- A generative assistance layer that interprets free text from tickets and chats and produces structured suggestions for on-call.
- An interactive interface for the operations center and platform teams that transparently shows current incidents, planned changes and escalations.
- Feedback loops in which teams confirm or adjust suggestions so that the workflow learns from decisions and improves its recommendations
How the agentic workflow runs in operations
Collect signals
The workflow continuously reads monitoring alarms, new tickets, planned changes from pipelines and relevant chat messages and maps them to services.
Assess context and criticality
The system adds business impact, dependencies and history to technical data, detects conflicts between incidents and changes and assesses urgency.
Generate suggestions
Generative components formulate prioritized suggestions for action, group similar incidents and create structured overviews for on-call and platform teams.
Guide and document teams' work
The operations center and platform teams work with the interface and confirm or correct suggestions, while the workflow documents decisions for audits.
Learn from feedback
Confirmed and rejected recommendations feed into the assessment logic, so the workflow increasingly takes typical patterns and service specifics into account.
Measured: after six months in production
Period: after six months in production.
| Metric | Value | Basis |
|---|---|---|
| Processing time per incidentKey metric | from 40 to 24 minutes per incident | Time tracking before/aftermeasured |
| Time spent on coordination | around 3,000 hours less per year | Projectionestimated |
| Quality of suggestionsQuality metric | usable without rework in 85% of cases | Samplemeasured |
Cost-effectiveness
The workflow depends on stable interfaces and well-maintained service catalogs. During restructuring or with poorly documented services, the quality of suggestions drops, so teams have to intervene manually more often and plan time for reviews.
Integration and operation
Transferability
The pattern of bundling technical and organizational signals in an agentic workflow transfers well to other complex operating environments. Wherever several systems, free-text descriptions and parallel interventions come together, such an approach can help make critical cases visible earlier and relieve specialists of manual coordination. What matters is having a basic catalog of objects, criticality and dependencies that the workflow can use and gradually refine.
A similar case in your organization? Let's talk.
Briefly describe your process. We'll get back to you with an initial assessment of whether the pattern can be transferred and what it would realistically take.