# One switch down is not a service down · Stilla > Impact analysis that ignores redundancy reports hundreds of "degraded" items and wakes people up for alerts that only repeat one cause. URL: https://stilla.eywo.digital/en/blog/redundancy-aware-impact/ Language: en Last updated: 2026-10-29 [← Back to the blog](https://stilla.eywo.digital/en/blog/) Operations29 October 20265 min readEywo team # One switch down is not a service down Impact analysis that ignores redundancy reports hundreds of "degraded" items and wakes people up for alerts that only repeat one cause. Stilla now calculates impact and event correlation from what would actually happen. At two in the morning, one of the two switches in a rack fails. The servers are connected to both, so the services keep running. Monitoring still raises dozens of alerts, the dependency map turns red, and at the morning meeting service owners read that their service was "degraded". It was not. It only ran without a backup for a few hours. The opposite case is worse. Five virtual servers alert while the host they run on stays silent, because monitoring cannot see it. Five separate reports appear, five people start investigating their own server, and the real cause goes unnoticed. Both problems have the same root: the tool knows what is connected to what, but not what an outage of one part would actually cause. ## Reach is not impact Most CMDBs can answer the question of what depends on an item. An honest answer needs more than a list of relationships: - **Redundancy.** A server connected to two switches survives the loss of one. But a firewall does not stand in for a switch, and a management network interface does not stand in for a data interface. - **The state of items.** A planned second switch that is not yet in service backs up nothing. A component under maintenance is effectively out of service during the change. - **The kind of relationship.** Management (the console that controls a server), replication and backup do not propagate outages. A server does not stop working because its replica went down. When a tool cannot tell these apart, every impact analysis is exaggerated. People stop trusting it and go back to estimates in meetings. ## Three states instead of two Stilla now distinguishes three situations: - **Outage** – the item does not work because all of its supporting components failed. - **Degraded** – the item works without some functions or with lower performance. - **At risk** – only one of the redundant components failed. The item keeps running, but without a backup. "At risk" is shown on the nearest dependent item and on the services above it, which are labelled "no redundancy". It does not propagate further. Losing one switch of a pair therefore no longer marks hundreds of items, only what actually lost its backup. Losing both switches is, correctly, an outage. Other parts of the product rely on the same calculation. When a change is planned on a redundant component, the service owner is informed that the service will run without a backup, but does not need to approve anything, and the change can be done outside the maintenance window. The single-point-of-failure check treats planned items as missing, so hidden weak spots surface before they cause trouble. ## A map that shows what would happen The dependency map has three changes: - **Management relationships are a separate layer**, off by default. The view of what a service depends on therefore shows only real dependencies, not everything that manages it. - **The view of what depends on an item simulates its outage straight away.** Coloured items would be affected; grey ones depend on it only redundantly or through management. - **The impact path** highlights the chain from the cause to each affected service, including the ports, interfaces and zones on the way. You can see how an outage reaches a service and explain it to management or to a customer. ## Event correlation with the same logic Event management merges related alerts into one situation and marks the probable cause. It now does so with an outage simulation: - **Only an item whose outage really explains the alerts can be the cause.** An alert on one switch of a pair is therefore not the cause of an outage of the server below it, and the operator does not go after the wrong item. - **Among several candidates, the one that explains the most alerts wins.** When a virtual server, its host and its datastore all alert, the situation gets the deeper cause, not the first one in time. - **Alerts explained by the cause are symptoms.** They are visible in the situation, but send no notifications, are excluded from noise metrics and are resolved together with the cause. - **Inferred cause.** When several items alert and their common supporting component stays silent, Stilla infers it from the CMDB and creates one situation marked "inferred from topology". The operator knows where to start, even when monitoring cannot see that item. The priority of an alert and of a pre-filled incident follows the real impact on the service. An alert on a redundant component therefore no longer gets the priority of a critical service it does not threaten, and the operator's queue stays cleaner. ## Processes that connect A fix is usually made by a change. One change can resolve several incidents and a problem, and its outcome is written to all linked records. A problem with a documented root cause moves to Resolved after a successful change, a failed change returns it to analysis, and the reporters of the incidents are notified. If alerts appear on the change's items after it is completed, the post-implementation review is required and an incident can be created with one click. ## Conclusion Impact analysis is only worth something when people trust it. That is why it has to tell an outage from a lost backup, and the same numbers have to hold when a change is planned, during an incident and at the moment monitoring reports dozens of alerts. For operations, this means fewer night calls about symptoms, a faster route to the real cause and meetings where nobody argues about impact. The dependency map, the three impact states, the impact path and linking changes to incidents and problems are part of the Standard edition. Event correlation by outage simulation, symptoms and inferred causes belong to the Business edition. **Stilla Business** For operations that want to connect monitoring, security and vendors. [Compare editions →](https://stilla.eywo.digital/en/editions/) ## More articles [Operations·20 August 2026 ### Major incidents: coordination instead of chaos In a major incident, the technology is only half the problem. The other half is who knows what, and when. Here is how to turn the first minutes into coordinated work instead of a hunt for information. Business3 min read](https://stilla.eywo.digital/en/blog/major-incident-coordination/)[Operations·6 August 2026 ### SLAs measured the right way A deadline that runs through weekends and holidays, or ignores time spent waiting on the customer, creates needless disputes. How to measure SLAs so the numbers match both the agreement and reality. Standard3 min read](https://stilla.eywo.digital/en/blog/sla-measured-right/)[Operations·30 July 2026 ### Monitoring noise: from thousands of alerts to a few situations When monitoring reports everything, it effectively reports nothing. How to turn a stream of events into a few clear situations with a probable cause and a visible impact on services. Business3 min read](https://stilla.eywo.digital/en/blog/monitoring-noise/)