SNMP Active Sessions OID: hrSystemNumUsers Reference

By the SNMP Monitoring team · Reviewed July 2026

There's exactly one standard OID for "how many people are logged in," and it's hrSystemNumUsers. It's a single number — no usernames, no source IPs, no per-session detail — which is both its limitation and, honestly, its charm: it's cheap, universal, and perfect as an anomaly tripwire. This page is the paste-ready reference for that OID, what it counts, and the hard limits on what it can tell you.

The "how do I actually alert on suspicious logins" side is the twin: monitor SSH sessions. Hubs: sensors, all OIDs.

The hrSystemNumUsers OID

One scalar from HOST-RESOURCES-MIB holds the active session count:

It's a Gauge32 — a snapshot that goes up and down as people log in and out, not a cumulative counter you diff. Append the trailing .0 for a GET; it's a scalar. On a Linux host it broadly tracks what who would show — interactive login sessions, including SSH.

What it does NOT show

This is the important half of the page, because the OID is easy to over-trust. hrSystemNumUsers gives you a bare integer and nothing else:

• No usernames — you can't tell who is logged in from this object.
• No source IPs — no idea where the sessions came from.
• No per-session detail — no start times, no idle time, no TTY.
• No protocol breakdown — it doesn't separate SSH from console or other login types.
• No history — it's the count right now; SNMP doesn't keep the past for you.

So SNMP answers "how many," never "who" or "from where." For identity you need the auth logs (/var/log/auth.log, wtmp, your SIEM) — SNMP is the fast signal that something changed, and the logs are where you go to find out what.

It's also worth being precise about what counts as a "user session" here, because the number can surprise you. hrSystemNumUsers reflects the host's own notion of logged-in users — on a Unix box that's roughly the utmp/who view: interactive TTYs and PTYs, which includes SSH sessions, local console logins, and each terminal a user opens. That has a few practical consequences. A single person with three SSH windows open counts as three, not one. A screen or tmux session, or a display manager, can add to the count in ways that look odd until you know the host's accounting. And service or daemon activity that never opens a login session doesn't register at all — this object is about interactive logins, not connections in general. None of that makes the OID less useful; it just means you baseline the number for that specific host rather than assuming a universal meaning, because "normal" depends on how the machine is used and what login mechanisms are in play.

Worked snmpget example

It's a scalar, so snmpget with the .0:

snmpget -v2c -c <RO_string> <host> 1.3.6.1.2.1.25.1.5.0

HOST-RESOURCES-MIB::hrSystemNumUsers.0 = Gauge32: 3

Three active sessions right now. Poll it on your normal interval and you get a live line you can graph and threshold. <RO_string> is a placeholder — allowlist this exact OID for an external poller rather than opening the branch, and keep live communities out of committed scripts.

Interpreting changes

A bare count is only useful once you know what "normal" looks like. The pattern:

1. Baseline it — watch the value over a few normal days to learn the typical range (often 0–2 on an unattended server).
2. Alert on deviation — a jump well above baseline, or any session on a box that's supposed to have zero interactive logins, is the interesting event.
3. Correlate with the clock — three sessions at 2 p.m. during a maintenance window is fine; the same three at 3 a.m. on a quiet night is worth a look.
4. Pivot to the logs — once SNMP flags the anomaly, go to the auth logs for the who/where SNMP can't give you.

The single most valuable rule: on a server that should have no interactive users, alert on hrSystemNumUsers > 0. That turns a coarse count into a genuinely useful unauthorized-access tripwire. Pairing it with physical-access signals like a door contact makes the story even clearer.

Related OIDs

hrSystemNumUsers sits alongside the other HOST-RESOURCES system scalars, and they're often watched together:

• hrSystemProcesses (1.3.6.1.2.1.25.1.6.0) — process count; see process OIDs.
• hrSystemUptime (1.3.6.1.2.1.25.1.1.0) — host uptime; see uptime OIDs.

A session spike right after an uptime reset (a reboot) tells a different story than a session spike on a box that's been up for weeks — which is why these coarse system scalars are more useful read as a set than in isolation. The full list is in the OID catalog.

How to monitor sessions (how-to)

Reference stops here. The alerting logic — baselining, zero-login tripwires, correlating with auth logs and physical access — is the twin: monitor SSH sessions via SNMP. Related: process OIDs, uptime OIDs, the OID catalog, and glossary.

Frequently asked questions

What OID shows active users in SNMP?

hrSystemNumUsers at 1.3.6.1.2.1.25.1.5.0 from HOST-RESOURCES-MIB. It's a Gauge32 holding the current number of active user sessions on the host, including SSH logins. It's a scalar, so read it with a GET on the .0 instance.

Can SNMP show which usernames are logged in?

No. hrSystemNumUsers is only a count — it carries no usernames, source IPs, TTYs, or per-session detail. For identity you have to go to the host's auth logs or a SIEM. SNMP tells you how many sessions exist and that the number changed, not who is behind them.

What type is hrSystemNumUsers?

It's a Gauge32 — a current-value snapshot that rises and falls as users log in and out, not a cumulative counter. That means you read it directly rather than diffing two polls, and you alert on its absolute value against a baseline.

How do I baseline session counts?

Poll the OID over a few normal days to learn the typical range, then alert on meaningful deviation from it. On servers that should have no interactive logins, the simplest and strongest rule is to alert whenever the value exceeds zero, then pivot to the auth logs to see who connected.

Key takeaways

• Active sessions = hrSystemNumUsers at 1.3.6.1.2.1.25.1.5.0, a Gauge32 count.
• It's count-only — no usernames, IPs, times, or protocol; go to auth logs for identity.
• Read it directly (it's a gauge), not as a diff; append .0 for the GET.
• Baseline, then alert on deviation; on no-login boxes, alert on > 0.
• Read it alongside hrSystemProcesses and hrSystemUptime for context.
• Procedure: SSH sessions how-to; catalog: sensors/all.