Login activity
The Login activity page answers two questions: how much data is each login being handed, and is that unusual for that login at this hour of the week.
It exists mainly as an exfiltration signal. A reporting account pulling two million rows at 09:00 on a Tuesday is doing its job; the same account pulling two million rows at 03:00 on a Sunday is not. No absolute threshold can separate those two, which is why the baseline is bucketed by weekday and hour rather than being a single number.
What is measured
Every few minutes the monitor reads sys.dm_exec_sessions and aggregates per login:
- Rows returned — the headline. The closest thing SQL Server offers to "how much data has this login taken".
- Logical reads and CPU — supporting volume figures.
- Sessions and active requests.
- Host and client program — a login appearing from a machine it has never used is one of the stronger hints, and often more telling than the volume itself.
Why the numbers are a floor, not an exact count
The counters in that DMV are cumulative for the life of a session, and with connection pooling a session can stay open for weeks. The monitor therefore stores the difference between two consecutive samples, per session.
The consequence is deliberate and worth knowing: whatever a session did between the last sample and the moment it closed is not counted. The figures are therefore "at least this much". That is the safe direction for a security signal — it can under-report, but it cannot invent traffic that did not happen.
Warm-up
A weekday/hour bucket needs a minimum number of observations (20 by default) before anything is judged against it — roughly a fortnight. Until then the page reports nothing, on purpose: a fortnight of noise while the baselines fill teaches everyone to ignore the feature before it ever works.
The banner at the top of the page shows how far along that is. Read it before treating an empty anomaly list as "all clear" — "nothing unusual" and "not yet able to tell" are very different statements.
The reporting floor
Volumes below 50 000 rows are never reported however unusual they are. Two rows becoming twenty is a ten-sigma event and completely meaningless; a detector that reports it gets muted within a week, taking the real findings with it.
Both the floor and the warm-up minimum are configurable under LoginActivity in
appsettings.json.
Levels
| Level | Meaning |
|---|---|
| High | Five or more standard deviations above the usual volume for this bucket, ten times the usual where the baseline is perfectly flat, or a login that has never returned rows in this hour of the week before. Raises an alert. |
| Notable | Three to five standard deviations above. Recorded and shown here, but does not alert by default. |
Findings can be acknowledged, which is recorded in the audit log — reviewing a possible exfiltration finding is itself worth a trace.
What this does not do
It sees volume and origin, not content. It cannot tell you which tables were read or what left the building — for that you need SQL Server Audit or Extended Events. Treat a finding here as a reason to go and look, not as proof.
Service accounts are excluded by default (ExcludedLogins); their read volumes are huge
and meaningless. Add your own backup or ETL accounts there if they drown out the signal.
Permissions
Reading sys.dm_exec_sessions needs VIEW SERVER STATE — on SQL Server 2022 and newer,
VIEW SERVER PERFORMANCE STATE. Without it the page reports that nothing has been
collected rather than an empty result.