The Severity 2 Black Hole in Microsoft Support.

When a Severity 1 incident hits, everyone knows what to do.

Executives join the bridge. Engineers clear their calendars. Vendors escalate. The business impact is visible, urgent and difficult to ignore.

Severity 2 is different.

The system still works, at least partially. The issue is serious, but it may not trigger an executive crisis. The ticket remains with the operating team. Updates slow. Ownership moves. A workaround becomes normal. Days accumulate quietly.

Across a large support environment, that quiet accumulation can cost more than the dramatic outage.

US Cloud analyzed historical Microsoft case data supplied by enterprise customers and compared it with US Cloud’s 2026 year-to-date case population. The most important finding was not about the highest severity. It was the extraordinary amount of time concentrated in Severity 2.

The dataset produced the following average days-open results:

The Severity 2 number deserves careful treatment. An 89.19-day average is so large that the responsible response is not a victory lap. It is methodological scrutiny.

“Days open” is also not automatically the same as “time to technical resolution.” Depending on the underlying case record, it may include time waiting on the provider, the customer, a third party or administrative closure. Averages can be pulled upward by a long tail of very old cases. Differences in customer mix, workloads, severity assignment and closure practice can affect comparisons.

Those limitations should be published beside the findings, not buried beneath them.

But even with those qualifications, the pattern points to a management problem enterprise leaders should investigate: high-priority cases can remain open long enough to become accepted operating conditions.

Severity 2 sits in an uncomfortable middle.

It is serious enough to consume skilled engineers but not always serious enough to maintain executive pressure. The provider may meet an initial-response target while the case waits for the right specialist. The customer may be asked for logs, traces or reproductions that require hours of internal effort. Teams in different time zones can trade one update per day. Escalations may add coordinators without adding technical progress.

The case is active, but the problem is not moving.

There are several recurring causes:

• Ambiguous ownership. Multiple Microsoft products or vendors are involved, so each team investigates only its boundary.
• Queue-based expertise. The first engineer is not equipped for the complexity and the case moves through tiers.
• Weak escalation triggers. Escalation is tied to severity or customer pressure rather than elapsed time without progress.
• Workaround complacency. A temporary mitigation reduces urgency even while cost and risk continue.
• Customer fatigue. Internal teams stop pushing because the effort required exceeds the expected benefit.

That last category is rarely measured. A ticket that closes after the customer gives up can look successful in an administrative report.

Enterprise support contracts often emphasize initial response because it is easy to define and audit.

Initial response matters. A severe incident should never sit unacknowledged. But acknowledgement is the beginning of service, not the outcome.

A provider can meet a 30-minute response commitment and still take weeks to place the right engineer on the issue. The dashboard remains green while the customer continues to operate around the defect.

Procurement should distinguish four clocks:

1. Initial response: When the provider first acknowledges the case.
2. Meaningful engagement: When a qualified engineer begins productive diagnostic work.
3. Restoration or workaround: When business operations return to an acceptable state.
4. Technical resolution: When the underlying issue is fixed or a final, accepted disposition is documented.

Those clocks answer different questions. Collapsing them into “response” makes a support organization look faster than the customer experiences it.

A prolonged Severity 2 case may not stop revenue immediately, but it can tax the enterprise every day.

Engineers attend recurring calls. Service managers write escalation summaries. Users repeat failed processes. Project teams postpone changes. Security teams accept temporary exceptions. Leaders spend political capital deciding whether to escalate again.

Multiply that effort across hundreds of cases and the loss becomes material.

This is why I would add a second measure to the normal time-to-resolution dashboard:

Customer effort days = Internal people assigned multiplied by the days the issue remains active

It is intentionally simple. Five employees spending part of every day on a 20-day support issue is not the same cost as one engineer resolving it in two days, even if both cases ultimately close.

The measure can be refined with actual hours and loaded labor rates. Its first purpose is cultural: to stop treating customer effort as free.

Support SLAs should not rely on initial response alone. For Severity 1 and Severity 2 cases, procurement should require:

• A definition of meaningful technical engagement
• Named ownership that persists through resolution
• Time-based escalation when progress stalls
• Regular communication intervals tied to severity
• A documented path to senior engineering and product escalation
• Reporting on restoration, resolution and customer effort
• Service credits tied to measurable performance, not administrative activity

Not every case can have a guaranteed resolution time. Complex defects, third-party dependencies and customer-controlled actions make absolute guarantees unrealistic. But a provider can commit to qualified engagement, continuity of ownership, escalation behavior and transparent reporting.

That is the difference between promising an answer and promising disciplined action.

CIOs should ask to see the age distribution of open cases, not just the average. Procurement should request the median, 75th percentile, 90th percentile and oldest open cases by severity and workload. Service owners should review every Severity 2 case that crosses a defined threshold without meaningful progress.

The most revealing report may be the cohort that never became Severity 1 but remained open for 30, 60 or 90 days.

That is where temporary workarounds become permanent processes and where support friction becomes hidden operating cost.

1. How many Severity 2 cases have been open more than 30 days, and who owns the next technical action?
2. Do our dashboards measure meaningful engagement and resolution, or only acknowledgement and closure?
3. How much internal engineering time did our ten oldest cases consume?

The lesson from 75,677 tickets is not that every Microsoft case takes too long. It is that averages at the top of the queue can conceal a long tail of operational drag in the middle.

Severity 1 creates the visible crisis. Severity 2 can create the invisible tax.

Download the complete Microsoft Support Performance Benchmark to evaluate the pattern by severity, workload and case age.

The Microsoft comparison uses 75,677 historical support tickets collected from US Cloud customers. The US Cloud comparison uses more than 10,000 cases from 2026 year-to-date operations. Values shown are arithmetic averages of days open within the stated severity cohorts. The populations are observational and are not randomized or matched case for case. Workload mix, enterprise profile, severity classification, open-case treatment, customer wait time and closure practices may differ. The analysis should be published with validated extraction dates, inclusion rules, treatment of still-open cases, medians and percentile distributions when those fields are available. Results establish a material performance signal for investigation; they do not by themselves prove causation.

• US Cloud enterprise support case dataset, 75,677 historical Microsoft tickets
• US Cloud 2026 year-to-date support operations dataset, more than 10,000 tickets
• Microsoft Unified frequently asked questions
• Microsoft Unified plan details