Use case 03
The problem that does not exist yet
When degradation has already started but the alarm has not arrived — and the window to intervene is still open.
Without EVA: the alarm arrives in week 4, when the threshold is crossed. The window to intervene is already gone.
EVA detected the deviation in week 1 — 3 weeks before the failure.
There is a chart that shows up in almost every post-mortem meeting. It shows the last thirty days of behavior of a link, a storage array or a service. And somewhere on that chart there is an inflection. A moment when the curve started moving in the wrong direction.
Nobody saw it. Not because nobody was watching, but because no threshold was crossed. The monitoring system raised no alarm. The dashboard did not change color. Everything looked green while the problem was building in silence.
When the alarm finally arrived, the window to intervene was already gone. What could have been a scheduled maintenance window became a 3am incident. What could have been an advance notice to the customer became an apology call. The failure was not sudden. It only looked sudden.
The limit of fixed thresholds
Traditional monitoring systems have a blind spot
They work on binary logic: above the threshold, alarm; below it, silence. Useful logic, but incomplete, because it assumes the normal behavior of every element is static and known in advance.
Fixed threshold logic
Detects when something failed
The value crosses the configured threshold. The alarm arrives. The window to intervene is usually gone. What follows is crisis management, not prevention.
Dynamic baseline logic
Detects when something is failing
Behavior deviates from its own history. The anomaly is detected weeks before the threshold is crossed. What follows is an informed decision with room to act.
The trajectory of a silent problem
Three weeks. Three possible decisions.
The same scenario — a transmission link with rising latency — produces completely different outcomes depending on whether the degradation is detected in time or only when the threshold is crossed.
- W1Anomaly detected
Week 1 — The deviation
The problem exists. EVA detects it.
A transmission link starts showing latency slightly above its historical behavior. The value is within configured ranges — there is no alarm. But the trend exists, and EVA identifies it as a statistical deviation from the baseline of that specific link at that specific time of day.
- Early anomaly detection — behavior deviated from its own history, not from a generic threshold.
- Correlation with context — EVA checks against recent changes: was there a configuration update? A traffic increase from a specific customer?
- Preventive alert — the team gets a heads-up while there is still time to act.
The team has actionable information before the problem becomes urgent.
- W2Trend confirmed
Week 2 — The confirmed trend
The deterioration persists. Impact is projected.
The anomaly was not an isolated event. The deviation persists and EVA confirms the trend: the link’s behavior is deteriorating consistently. The model projects the crossing point of the critical threshold with a margin of days.
- Impact projection — an estimate of when degradation will reach critical levels if nothing is done.
- Scope identification — which services and customers would be exposed if the deterioration continues.
- Preventive ticket created — the incident opens as scheduled maintenance work, not as an emergency.
The conversation with the customer happens in planning mode, not in apology mode.
- W3Preventively resolved
Week 3 — The moment that never comes
The intervention happened. There is no incident.
If the intervention happened in time, there is no incident. No 3am call, no post-mortem, no chart to show at the next meeting. There is a note in the system saying a trend was detected, a preventive ticket was opened and it was resolved during a scheduled window.
- Coordinated maintenance window — scheduled with the customer, with no production impact.
- Proactive customer communication — advance notice instead of an apology call.
- Recorded in the learning log — the pattern is documented for earlier detection on recurrences.
The hardest outcome to show on a dashboard — and the most valuable one for the customer’s business.
The hardest metric to measure
The incident that never happened
The most valuable outcome of early detection is a number that appears in no report: the incidents that never became incidents.
There is no alarm to count, no MTTR to report, no customer who called. There is an operation that worked, a maintenance window that passed without impact, and a customer who never had to wait.
That silence is the goal. And it is the difference between an operator who responds and an operator who takes care.
Scenario comparison — same link
Specific values depend on each client’s operational volume and infrastructure. EVA sizes the expected results based on the real data of the environment.
Why this changes the conversation with the customer
From answering incidents to selling continuity
An operator that detects and resolves problems before they impact the customer is not selling response time — it is selling continuity. And that is a completely different commercial conversation.
The indicator that improves with proactive operation
Not just a lower MTTR
Incidents that never happened
The customer who receives a notice saying "we detected a degradation trend on your link and scheduled preventive maintenance for Thursday" is not evaluating whether the operator responded quickly. They are evaluating whether the operator takes care of their operation as if it were their own.
Early detection is not just a technical capability. It is the strongest argument to renew a contract, to stand apart from a competitor offering the same service at the same price, and to build the reputation of an operator that does not wait for problems to happen.
Let’s talk about your operation
No generic proposal, no filler slide deck — with your real operation on the table.