It is Tuesday afternoon and a critical service stops working. Phones ring, the chat fills up, and three teams look for the cause, each in their own layer. The head of operations tries to work out who is affected, the service desk wants to know what to tell callers, and management asks when it will be fixed. Nobody has the full picture.
A major incident is a stress test for people as much as for systems. Engineers work under pressure while answering the same questions again and again. External updates are written in a hurry and often contradict each other. And once it is over, it is hard to reconstruct what happened when, and why.
Why the runbook alone is not enough
We often see organizations with a well-written major incident procedure. The trouble is elsewhere. When the procedure is needed, the information required to follow it is missing:
- Impact is guessed. Who knows which services run on the affected server? Often one person, who is busy with something else.
- Changes are reconstructed after the fact. “Did anyone change something?” is always asked. The answer comes from emails and memory.
- Vendors are contacted ad hoc. Who holds the contract, what response time it promises and whom to call are dug out of a shared folder.
- Communication starts from a blank page. Different every time, written under pressure every time.
All of this information exists somewhere in the organization. It just is not at hand when it matters.
Coordination runs on shared facts
A well-run major incident has a clear coordinator, a single source of truth and a steady rhythm of updates. But the coordinator needs facts, not guesses: which services and customers are affected, what changed recently around the affected components, who is responsible on the vendor side, and who needs to be informed. The more of that is ready in advance, the more capacity is left for the actual fix.
How Eywo Stratum handles it
Eywo Stratum ties the incident to data that is already in the system. When an incident is raised against a CMDB item, it suggests the affected service, the impact and the resolver team. Priority follows from impact and urgency. The incident can be flagged as major so it gets the handling it deserves.
When the incident starts in monitoring, event management groups related alerts into a situation based on CMDB topology, service and time, and shows the probable cause along with related changes. An incident is created from the situation in one step, or automatically. The team starts from one situation with context, not from a thousand separate alerts.
If part of the resolution sits with a vendor, the incident can be escalated according to the service contract. The system knows which items the contract covers and what SLA the vendor has committed to. Nobody searches for a contract while the clock is running.
Email and Slack notifications follow rules and templates. The right people hear about the incident without a round of phone calls, and messages look consistent.
The optional AI assistant helps where time is lost under pressure. It proposes an incident from a situation, finds similar past incidents and drafts customer communications. These are suggestions, not decisions. A person always decides what is sent and how to proceed.
Afterwards, the full timeline stays in the audit trail. The post-incident review rests on a record, not on recollection.
Calm when it counts
Major incidents cannot be ruled out. What you can ensure is that the first minutes are not spent looking for information. When impact is known, changes are traceable, the vendor is a click away and communication is drafted, engineers can focus on the fix and the coordinator on the people. And when it is over, everyone can go home knowing the response was based on facts.
Major incidents are part of the Standard edition; event correlation into situations, contract-based vendor escalation and the AI assistant are included in the Business edition.
Eywo Stratum Business
For operations that want to connect monitoring, security and vendors.