Twenty-five events is a lot to watch. It’s also a lot to get pinged about, if every single one of them lands with the same urgency as every other. Set it up carelessly and you end up with two equally bad outcomes: either you turn most of it off out of sheer notification fatigue, or you leave it all on and slowly train yourself to swipe every Login AlertX message away without reading it. Either way, you’ve quietly defeated the whole point.
The fix isn’t picking fewer events. It’s deciding which ones actually deserve to interrupt you, and being deliberate about where each one goes.
All 25 events, and which ones deserve a loud alert
Login AlertX groups its 25 events into four categories, and that grouping is actually a useful starting point for deciding what deserves your attention in real time versus what’s just worth having on record.
Logins & Authentication
| Event | Suggested tier |
|---|---|
| User Logged In | Contextual |
| First Login on this Device | Contextual |
| Failed Login Attempt | Critical |
| Brute-Force Attack Detected | Critical |
| Login After Lock | Critical |
| Login After Logoff | Contextual |
| Privilege Elevation (sudo / UAC) | Critical |
Privilege Elevation is worth calling out specifically. It’s arguably the single most important event on this entire list, more so than the login itself, because it’s the exact moment something moved from having access to having control.
Remote Access
| Event | Suggested tier |
|---|---|
| SSH Login | Critical |
| Remote Desktop Connection | Critical |
| First Remote Desktop Connection | Critical |
| RDP Reconnected | Contextual |
| RDP Disconnected | Contextual |
| RDP Post-Logoff | Critical |
| RDP Wake Connect | Critical |
Anything genuinely remote deserves default weight toward critical, since it means access happened over a network rather than in front of the machine. Reconnect and disconnect are the exceptions, they’re just state changes on a session you’ve already been alerted about, not new access.
Sessions & Sleep
| Event | Suggested tier |
|---|---|
| Screen Locked | Contextual |
| Screen Unlocked | Contextual |
| User Logged Off | Contextual |
| Computer Woke Up | Contextual |
| Computer Went to Sleep | Contextual |
System Power & Lifecycle
| Event | Suggested tier |
|---|---|
| Computer Powered On | Contextual |
| User Shutdown / Restart | Contextual |
| Computer Powered Off | Contextual |
| Computer Hibernated | Contextual |
| Computer Resumed | Contextual |
| Unexpected Restart Detected | Critical |
An unexpected restart is the one exception in this otherwise routine category, since it means the system came back up without a clean shutdown ever happening, which is worth knowing about rather than just logging.
That’s thirteen events genuinely worth an instant alert, and twelve that are more useful as a quiet record you can look back on than something worth interrupting your day for. Where exactly you draw the line is personal. Someone watching a machine other people also use might want screen unlocks in the loud tier too, since “who’s using it right now” is closer to their actual worry than it would be for someone monitoring a laptop nobody else touches.
8 channels, and why no single one is a safe bet
Login AlertX can send an alert to Email, WhatsApp, Push Notification, Slack, Microsoft Teams, Discord, Telegram, or Google Chat, individually or in any combination.
Here’s the part that’s easy to overlook once you’ve picked your loud-tier events: none of these channels is something Login AlertX fully controls end to end, and neither is anything else that sends you a message over the internet. Email can sit in a delivery queue on your provider’s end, or land in spam and just wait there. WhatsApp routes through a third-party messaging service that occasionally has its own slow moments, unrelated to your internet connection entirely. Slack, Teams, Discord, Telegram, and Google Chat each depend on that platform’s own service being fully healthy at that exact moment, which is usually true and occasionally isn’t. Push notifications are generally the closest thing to instant, and they’re still one more external service in the chain.
Worth knowing specifically: Google Chat delivers text only. If a critical alert is meant to carry a webcam photo, a screenshot, or an audio clip as evidence, Google Chat won’t show it, every other channel on this list will. Worth factoring in if that channel is part of your critical-tier routing.
None of this is a flaw specific to any one channel. It’s just what happens when a message has to travel through someone else’s infrastructure before it reaches you. On most days you’d never notice, because most days everything is fast. The moment that matters is the rare one where it isn’t, and that’s precisely the moment you can least afford a delay.
Worth being clear about what this isn’t: it’s a different problem from your own internet being down entirely, which Login AlertX handles separately by queuing the event locally and sending it the instant your connection is back. This is about the case where you’re online and everything looks normal, but one specific channel’s delivery pipeline is having a slow day on its own.
Redundancy is only affordable once you’ve tiered
This is really where the two ideas meet. Sending all 25 events to several channels at once would just multiply your notification fatigue for no real benefit, since most of those events didn’t need urgent delivery in the first place. But once you’ve decided your critical tier is genuinely thirteen events, or fewer, sending only those to two channels stops being excessive and starts being simple insurance. If email happens to be slow that exact minute, a push notification or WhatsApp message has almost certainly already reached you. You lose nothing by not needing that redundancy 99% of the time, and you gain everything the one time you do.
A setup that reflects this might look like: Failed Login, Brute-Force Attack Detected, Privilege Elevation, and the Remote Access events routed to both Push Notification and WhatsApp. Everything in the Contextual column sent quietly to Email alone, or just left in the log for the occasional look-back.
The point of doing this properly
None of this is about squeezing more features out of the product. It’s about making sure that on the one day something actually needs your attention, you’re not the person who missed it because it arrived on the one channel that happened to be slow, or because you’d long since stopped reading Login AlertX notifications at all. Tiering and redundancy aren’t separate settings to configure once and forget. Together, they’re what makes sure the alert that matters most is the one you actually see.
Login AlertX monitors 25 security events across logins, remote access, sessions, and system power, and can route any of them to Email, WhatsApp, Push Notification, Slack, Microsoft Teams, Discord, Telegram, or Google Chat, individually or in combination. See how it works .