Introduction
Catch brute-force attempts and credential abuse before they succeed. The Failed Login monitor fires an alert when a device records failed login attempts at or above your threshold within a time window you define.
It's a native monitor that works on Windows, macOS, and Linux. No event IDs, no log parsing, no custom scripts.
Failed Login Monitor
Level reads failed authentication attempts from each operating system's own security logs, counts them over a rolling look-back window, and fires an alert when the count meets your Threshold.
The threshold-plus-window combination is what separates signal from noise. One mistyped password is a Tuesday. 10 failures in 5 minutes is an active attack.
What Gets Detected, Per Platform
Detection sources differ by OS, so coverage isn't identical everywhere. There's no per-OS configuration: assign the monitor policy to Windows, macOS, or Linux devices and the monitor works on all of them.
🖥️ PLATFORM NOTE:
Windows: Reads the Security event log (Event ID 4625) through a live subscription. Covers any failed logon Windows records: interactive, RDP, network, and so on. Detection is real-time.
macOS: Reads the unified log. Covers SSH failures, sudo and su failures, and GUI login window and lock screen failures. Checked every 10 seconds.
Linux: Reads
/var/log/btmp, the same bad-login recordlastbreads. Covers whatever PAM writes there: console, SSH, and so on. Checked every 10 seconds.
⚠️ WARNING: The monitor only sees what the OS logs. On Windows, failed-logon auditing must be enabled (it is by default). On Linux, detection depends on /var/log/btmp existing. Some distributions don't create it by default, and if it's missing, the agent reports nothing rather than an error. A quiet device isn't proof of zero failed logins.
💡 TIP: Before this monitor existed, the standard approach was an Event Log monitor watching Windows event ID 4625. The Failed Login monitor replaces that for most cases, and unlike the Event Log monitor, it covers macOS and Linux too.
Configuring Failed Login Monitor
Open the monitor policy you want to add this to, then click + Add new monitor (or open an existing Failed Login monitor to edit it). The configuration panel opens.
Name and Type
Enter a name in the Name field. Be specific about scope and intent: "Servers - Failed Admin Logins" reads better in an alert list than "Failed Login Alert."
Set Type to Failed login.
Severity
Set Severity to match how your team should respond:
Information — low priority, FYI-level
Warning — worth attention but not urgent
Critical — requires prompt response
Emergency — drop everything
💡 TIP: Critical is a sensible default here. Repeated failed logins on a server or admin account usually deserve a prompt look, even if most turn out to be a user who forgot their password after vacation.
Scope
Scope controls which accounts count toward the threshold:
All users — failed attempts from any account on the device count
Admin users only — only failed attempts against admin-level accounts count; non-admin failures are dropped before counting
What qualifies as an admin account depends on the platform:
🖥️ PLATFORM NOTE:
Windows: The built-in Administrator account, or membership in the local Administrators group.
macOS:
root, or membership in theadminorwheelgroup.Linux:
root, or membership in thesudo,wheel, orrootgroup.
💡 TIP: Run two monitors in the same policy: a broad All users monitor at Warning severity, and a tighter Admin users only monitor at Critical or Emergency. Attacks against privileged accounts deserve a louder alarm.
Threshold
Threshold sets the number of failed attempts that triggers the alert. Set it with the up/down arrows.
The comparison is meets-or-exceeds. With a threshold of 3, the 3rd failed attempt inside the window fires the alert. There's no consecutive-check requirement; the alert fires on the first evaluation that crosses the threshold.
Duration
Duration is the rolling look-back window the threshold is measured against. Attempts older than the window drop off the count.
Pick a unit from the dropdown, then set the value with the arrows or the slider:
Minutes — 1 to 120
Hours — 1 to 24
Shorter windows catch fast, automated attacks. Longer windows catch slow, deliberate ones. 3 attempts in 60 minutes is a reasonable starting point for workstations; tighten it for servers exposed to RDP or SSH.
ℹ️ NOTE: The window is rolling, not fixed. Level checks continuously (real-time on Windows, within seconds on macOS and Linux) and evaluates the trailing window, so counts don't reset at the top of the hour.
Remediation
Attach one or more automations to run when this alert fires. For failed logins, Lock Device is the obvious candidate: stop the attack first, investigate second.
Click in the Remediation field and select an automation.
To add more, click + Add another remediation.
To remove one, click the × next to it.
Each attached automation has 2 icons: the link icon opens the automation in a new tab, and the eye icon shows a quick preview of what it does.
⚠️ WARNING: Remediations run automatically the moment the alert is created. Pairing this monitor with a destructive automation (lock, wipe, disable account) on a loose threshold can lock out legitimate users who fat-finger a password a few times. Test your threshold against real-world behavior before attaching aggressive remediations.
Notify Recipients
Two checkboxes control whether the policy's recipients get emailed:
On alert creation — recipients get an email when the alert fires
On alert resolution — recipients get an email when the alert resolves
Recipients are configured at the monitor policy level, in the Recipients section. If no recipients are set on the policy, no emails go out regardless of these checkboxes.
Auto-Resolve
The Auto-resolve alert when conditions clear toggle controls whether Level closes the alert automatically once failed attempts drop back below the threshold within the look-back window.
Failed login alerts represent something that already happened, and a quiet window doesn't mean the event didn't matter. Leaving auto-resolve off keeps the alert open until a technician reviews it.
What the Alert Shows
When the monitor fires, the alert summarizes the count ("Detected 3 failed login attempts for users") followed by a per-attempt list of the user and source.
What appears in the source field depends on the platform:
🖥️ PLATFORM NOTE:
Windows: Username appears as
DOMAIN\user. Source is the originating IP, falling back to the workstation name.macOS: Source is the IP for SSH failures, "local" for sudo and su failures, and "login window" for GUI failures.
Linux: Source is the hostname recorded in btmp.
FAQ
Who can create and edit monitors? Technicians with access to the relevant monitor policy. Permission settings are managed in Workspace → Permissions.
Does this replace the Event Log monitor for failed logins? For most cases, yes. The Failed Login monitor is native, needs no event ID configuration, and works on all 3 platforms. The Event Log approach still makes sense if you want to watch related Windows event IDs this monitor doesn't cover, or combine failed logins with other security events in one monitor.
Which login types count? Whatever the OS records as a failed authentication. On Windows that's any Event ID 4625 logon failure (interactive, RDP, network). On macOS: SSH, sudo, su, and the GUI login window or lock screen. On Linux: anything PAM writes to btmp, including console and SSH.
What counts as an admin user with "Admin users only"? On Windows, the built-in Administrator account or members of the local Administrators group. On macOS, root or members of the admin or wheel group. On Linux, root or members of the sudo, wheel, or root group.
Do failed attempts against usernames that don't exist count? Yes. Level counts every failed attempt the OS records, whether or not the account exists on the device. SSH brute force against invalid usernames still trips the monitor.
Why does a Linux device never show failed logins, even when I know there are some? Check that
/var/log/btmpexists. Some distributions don't create it by default, and without it the agent has nothing to read. It reports zero rather than an error.Why didn't my alert fire? I know someone failed a login. The count has to meet or exceed the threshold within the duration window. Attempts older than the window drop off. Also confirm the device is covered by the policy's target tags, and that your Scope setting matches the account involved.
Can I set different thresholds for servers and workstations? Yes. Create separate monitor policies targeting different tags and configure each monitor's threshold independently.
What happens to open failed login alerts if I delete the monitor? Existing alerts remain in place. Deleting a monitor doesn't close alerts it already created. Resolve those manually.