Application Overload

Category: Query & Session · Also known as: Same Application Storm

One application opened many sessions at once - a burst of connections from a single program, above what it normally uses.

What this finding means

One application, identified by its program name, held an unusually large number of concurrent sessions against the instance. This is about the size of one caller’s footprint rather than about any individual query, and it is measured against what that same application normally uses at this time of day.

Why it matters

A single application consuming the session pool starves every other caller, including the monitoring and maintenance work that would tell you what is wrong. Where the cause is a connection leak, the pattern grows until connections are exhausted and the instance refuses new work, so catching it while it is still a finding rather than an outage is the point.

How WISdom detects it

Sessions in sys.dm_exec_sessions are grouped by program_name with host_name retained, and the concurrent session count per application is taken for the minute; connect times come from sys.dm_exec_connections. The count is compared to the same application in the 15 minutes either side of this minute-of-day across four weeks.


Collected from	sys.dm_exec_sessions grouped by program_name (with host_name); concurrent session count per application; connect times from sys.dm_exec_connections.
Compared with	Same application during 15 minutes before and 15 minutes after of the same minute in the past 4 weeks
Related screen	Workload Activity

How it is scored

This rule fires only when the condition is met. It contributes an incident score of 1 when the finding is present, 2 when it exceeds its four-week maximum, and 2 when it has never been seen before.

How to read the numbers

Concurrency and Sessions give the footprint. The Application and its host are what you hand to whoever owns that service. Check the connect times: sessions that all opened within a few seconds indicate a burst, while sessions opened steadily over a long period and never closed indicate a leak. Those two have completely different fixes.

What normally causes it

A connection-pool leak: connections opened and never returned, so the count climbs steadily and never recovers.
A fan-out job or scheduled task starting every worker simultaneously.
A deployment or scale-out event that raised the instance count of the application without changing the pool ceiling.
A retry storm in which each failed call opens a fresh connection.

What this finding is not

Not a per-query problem. The statements may all be fine. The finding is about how many sessions one caller holds.
Not always growth. A steady climb that never falls is a leak, not demand. Compare the shape over the hour before concluding you need more capacity.
Not meaningful when program_name is not set. Applications that do not set a connection string application name collapse into one generic bucket and can look like a single overloaded caller.

What are some possible resolutions?

The options below are ranked. Option 1 fixes the cause where it lives and costs nothing; option 3 spends money or escalates, so try it last.

1. Stagger or rate-limit the workload

One application is firing everything at once. Spread the fan-out or add a rate limit so the same work arrives across a window instead of in one burst.

2. Check the connection pool for a leak

A pool that never returns connections looks identical to a genuine load spike. Confirm pool size, lifetime, and disposal before assuming demand grew.

3. Isolate the noisy application

If the app cannot be changed, separate it: its own pool, its own workload group, or read traffic moved to a replica.