If Sift Can Find Passwords in Slack and Jira, What Is Your Monitoring Not Seeing?

Last week, Stratus Security shipped Sift — a free, open-source command-line tool that hunts for forgotten passwords, API keys, and other secrets across Microsoft 365, Slack, Jira, Confluence, Active Directory, Windows file shares, and local storage. The idea is simple and slightly uncomfortable: the credentials everyone assumed were sitting on file shares aren't there. They're in a Jira ticket from 2022 where a vendor pasted a license key, a Slack DM where someone shared a service-account password "just this once," a Confluence runbook nobody has opened since the last admin left.

Every secrets scanner before Sift scanned file shares. The secrets weren't there. The tools were looking where it was easy to look, not where the problem actually lived.

Now ask yourself the uncomfortable follow-up question: if a free tool can sweep seven systems in an afternoon, how much of your infrastructure does your monitoring actually sweep?

For most IT teams and MSPs, the honest answer is: a fraction of it.

Your Monitoring Scope Is Smaller Than Your Infrastructure

Most monitoring deployments weren't designed — they accumulated. An agent push to "the important servers" during a migration project in 2019. A handful of PRTG sensors added one at a time when something broke. An UptimeRobot check pinging the public website. Maybe an SNMP template on the core switch. If anyone asked "what are we monitoring?", the answer was whatever happened to have an agent.

Meanwhile, a huge amount of critical infrastructure sits outside that scope:

• The second domain controller nobody remembers exists — until DNS queries start timing out.
• Scheduled tasks: nightly backups, certificate renewals, data sync jobs. They fail with a non-zero exit code and nobody sees it, because nothing was watching the task — only the server it runs on.
• Windows services configured to restart on failure. Great — until the third failure, when recovery gives up and the service stays down. Usually at 2 a.m.
• Internal line-of-business applications — the quoting tool, the intranet, the IIS app pool — with no URL check, no service monitor, nothing.
• The NAS holding department shares, and the print server everyone mocks until finance can't print invoices.

This is exactly Sift's thesis applied to operations: conventional scanning stopped at the file share, so everything beyond it was invisible. Conventional monitoring stops at "has an agent," so everything beyond it is invisible. And silence doesn't read as "unmonitored" — it reads as healthy, right up until a user opens a ticket.

Why the Gaps Exist

These blind spots aren't carelessness. They're structural:

Agent-first architecture. Legacy RMM and monitoring platforms only see devices with their agent installed. No agent means no data, no error, no signal. An unmonitored server and a healthy server look identical in the console.

Per-node and per-sensor licensing. When every sensor counts against a license (the classic PRTG model) or every server adds cost, coverage becomes a budgeting decision. Teams triage: domain controllers and the ERP database get monitored; the file server, the app servers, and every workstation get a prayer.

Tool sprawl with no shared scope. The server agent lives in one console, uptime checks in a second, the helpdesk (ConnectWise, HaloPSA, Freshservice — pick your poison) in a third, network gear in a fourth. Each tool monitors its own slice. Nobody owns the union, so nobody notices the gap between the slices.

Alert fatigue on the covered 40%. Dumb thresholds on the systems you do monitor — CPU over 90% for 60 seconds, anyone? — train the team to ignore pages. So even if you expanded coverage tomorrow, half the alerts would be swiped away out of habit.

MSP reality. Inherited clients, undocumented environments, coverage that exists only in a former technician's head. You find out what wasn't monitored the same way you find out about everything else: a ticket.

What the Blind Spots Actually Cost

Concrete scenarios, because every sysadmin has lived at least one of these:

The disk that filled over nine days. A file server's D: volume — not the C: drive the agent template watched — grew 3% a week from shadow copies and user dumps. No threshold existed on D:. When it hit 100%, shadow copies failed first, then file saves. Fourteen tickets arrived before anyone correlated them to one root cause. Recovery, including shadow-storage cleanup and a service restart: half a day. A 15%-free threshold on that volume would have caught it nine days earlier as a one-line alert.

The backup that failed for three weeks. The task ran every night — and exited with code 1 every night. The server itself was healthy, so every server-level check stayed green. The first time anyone noticed was a restore request from legal. If your monitoring watches servers but not scheduled-task exit codes, your backups have an opinion about your DR plan that you haven't heard yet.

The IIS app pool that died at 07:40. Recycle-on-failure masked it twice that morning; the third crash stuck. Nine users ticketed it over 40 minutes before a tech remoted in and restarted it manually. Total user downtime: roughly 50 minutes. With a service monitor and a page: four minutes, most of it the restart.

The 2 a.m. page for nothing — while the thing actually failing (a stuck certificate-renewal task) has been quietly erroring for a month.

There's a reporting consequence too. When monitoring and helpdesk are separate systems, your SLA clock starts when the ticket is created — i.e., when the first user got annoyed enough to call. The 40 minutes of silent downtime before that? Invisible. Your SLA dashboards show green while your users experienced an outage. That's not an SLA report; that's fiction with a pie chart.

And there's a human cost: technicians stuck in permanent reaction mode — paged for noise while real failures arrive as angry tickets — burn out or leave. Ask any MSP owner what re-hiring a sysadmin costs.

How AlertMonitor Closes the Scope Gap

AlertMonitor was built around a simple premise: the monitoring scope should match the infrastructure, automatically, and everything should land in one alert stream.

Discovery instead of memorization. Point AlertMonitor at a subnet or domain and it finds the assets — servers, workstations, network devices, printers — whether or not someone remembered to add them. The second DC, the NAS, and the print server show up on their own. A blind spot has to exist in your inventory before it can hide in your monitoring.

Scheduled tasks and services as first-class monitors. AlertMonitor watches Windows service state and scheduled-task last-run results directly — exit codes, not just "the task exists." Non-zero result, missed run window, service stopped: that's an alert, not a footnote.

One platform, one alert stream. Infrastructure monitoring, application/URL checks, SNMP network monitoring, RMM remote access, patch management, and the integrated helpdesk live in the same product. There is no union-of-slices problem because there are no slices.

Intelligent alerting. Deduplication and correlation collapse the forty symptoms into one root-cause page. Escalation chains make sure it reaches the right on-call person in seconds — and the noisy thresholds that trained your team to ignore pages don't exist here.

SLA from detection, not from complaint. When an alert fires, it can open a ticket automatically, stamped at detection time. The helpdesk timeline starts when AlertMonitor knew — not when user number four called. That's the difference between an SLA report and the fiction described above.

Alert-to-fix without alt-tab. The page includes the server, the failing check, and a one-click remote session. No switching to a separate RMM tool, no hunting for credentials in a vault — or, if Sift is to be believed, in a Jira ticket.

The old workflow: user ticket → triage → remote tool → second tool to check whether monitoring saw anything (it didn't) → escalate → 45–90 minutes, three tools, one frustrated tech.

The AlertMonitor workflow: 02:14 service-failure alert → on-call paged with server, service, and runbook link → remote session in the same console → restart → monitor confirms recovery → ticket auto-resolved with a full timeline. Roughly four minutes, most of it the restart. Users find out via the morning status note, not a dead application.

What You Can Do Today

Before (or instead of) buying anything, measure your own gap. These are the same checks AlertMonitor runs continuously — run them once now and see what your current monitoring isn't telling you.

1. Find the servers, then find the silent services.

# Inventory every Windows server in the domain
$servers = Get-ADComputer -Filter 'OperatingSystem -like "*Server*"' -Properties OperatingSystem |
    Select-Object -ExpandProperty Name

# Flag critical services that are NOT running right now
$critical = 'NTDS','DNS','Netlogon','W32Time','MSSQLSERVER','Spooler'
foreach ($srv in $servers) {
    Get-Service -ComputerName $srv -Name $critical -ErrorAction SilentlyContinue |
        Where-Object Status -ne 'Running' |
        Select-Object @{n='Server';e={$srv}}, Name, Status
}

2. Audit scheduled tasks that failed recently — this is the backup-failure scenario in one script:

# Tasks that ran in the last 7 days and exited with an error
$servers = 'FS01','APP01','SQL01'
foreach ($srv in $servers) {
    Invoke-Command -ComputerName $srv -ScriptBlock {
        Get-ScheduledTask | Where-Object State -ne 'Disabled' | ForEach-Object {
            $i = $_ | Get-ScheduledTaskInfo
            if ($i.LastTaskResult -ne 0 -and $i.LastRunTime -gt (Get-Date).AddDays(-7)) {
                [PSCustomObject]@{
                    Server   = $env:COMPUTERNAME
                    Task     = $_.TaskName
                    LastRun  = $i.LastRunTime
                    ExitCode = $i.LastTaskResult
                }
            }
        }
    }
}

3. Check disk headroom across the whole estate — every volume, not just C::

# Any volume below 15% free space on key servers
Get-CimInstance -ComputerName 'DC01','FS01','APP01','SQL01' -ClassName Win32_LogicalDisk -Filter 'DriveType=3' |
    Select-Object SystemName, DeviceID,
        @{n='SizeGB';e={[math]::Round($_.Size/1GB,1)}},
        @{n='FreeGB';e={[math]::Round($_.FreeSpace/1GB,1)}},
        @{n='FreePct';e={[math]::Round(($_.FreeSpace/$_.Size)*100,1)}} |
    Where-Object FreePct -lt 15 | Sort-Object FreePct

4. Mixed Linux estate? Same idea:

# Failed systemd services on this host
systemctl list-units --type=service --state=failed

# Disk usage snapshot for threshold planning
df -h -x tmpfs -x devtmpfs

Here's the honest limitation: a script run once is a snapshot. It catches what has already broken. Run these same checks continuously — as monitors with thresholds, alerting, and auto-ticketing — and they catch problems while there's still time to fix them before a user notices. That's the difference between running Sift once and actually knowing where your secrets are.

Practical first week with AlertMonitor: run discovery against every subnet, enable service and scheduled-task monitors on everything it finds, set disk thresholds at 15% free, and connect the helpdesk so every alert that matters opens a ticket at detection time. One afternoon of setup, and the phrase "nobody was watching that" disappears from your post-incident reviews.

The Takeaway

Secrets scanners got dramatically better the moment someone asked, "Where do secrets actually live?" — and stopped assuming the file share was the whole story. Infrastructure monitoring gets better the same way. Outages don't live on the servers with agents; they live in scheduled tasks that exit 1, in services that stop at 2 a.m., on volumes no one thresholded, in apps no one URL-checked.

Your environment is bigger than your monitoring scope. The only question is whether you find the gap with a script and a Tuesday afternoon — or with a user's phone call.

Related Resources

AlertMonitor Infrastructure & Server Monitoring AlertMonitor Platform Overview Book a Demo Infrastructure & Server Monitoring Resources