DEV Community: OpsKit

How to get an email when a Windows scheduled task fails (without babysitting Task Scheduler)

OpsKit — Wed, 07 Oct 2026 10:46:33 +0000

Your backup job runs at 3 a.m. At 9 a.m. your manager asks why last night's export is missing.
You open Task Scheduler and see it: Last Run Result: 0x1. The task failed hours ago and
nothing told you.

Windows used to tell you. Task Scheduler had built-in email alerts - then they were removed
in Server 2016 and never came back. Everyone reinvents the same broken workaround, so here is
the version that actually works in production.

What people usually paste (and why it breaks)

The typical Google result is a script that loops over tasks, calls
Get-ScheduledTaskInfo, and mails you when LastTaskResult -ne 0. Roughly:

Get-ScheduledTask | Where-Object { $_.TaskPath -notlike '\Microsoft\Windows*' } | ForEach-Object {
    $info = $_ | Get-ScheduledTaskInfo
    if ($info.LastRunTime -gt (Get-Date).AddHours(-24) -and $info.LastTaskResult -ne 0) {
        Send-MailMessage -To me@example.com -From taskwatch@example.com `
            -Subject "Task failed: $($_.TaskName)" -SmtpServer smtp.example.com
    }
}

It works once. Then it burns you in one of three ways.

Trap 1: the `LastRunTime` seconds quirk

Get-ScheduledTaskInfo.LastRunTime has a long-standing bug where the seconds value can
mirror the minutes value. It has been reported through Microsoft Feedback Hub more than once
and it is still there. If you compute "how old is this run" with full timestamp precision,
a task that ran 5 minutes and 5 seconds ago can look like it ran 5 minutes and 55 seconds
ago - and anything with a tight window starts flapping.

The fix is boring and reliable: do age math at minute granularity and give yourself a
two-minute tolerance:

$ageMin = ((Get-Date) - $info.LastRunTime).TotalMinutes
if ($ageMin -gt ($maxAgeHours * 60) + 2) {
    # stale
}

A rounding quirk can never wake you up at 3 a.m.

Trap 2: the email flood

The naive script has no memory. It runs every 5 minutes, the task is still broken, and you
get 12 identical emails before your coffee. Worse, when the task recovers and fails again
next week, the "already alerted" logic you bolted on suppresses the new incident.

The correct model is a tiny state file keyed per watched item:

new problem -> alert, store a signature of the problem
same problem, within the re-alert window (24h) -> stay quiet
same problem, past the window -> one reminder
problem gone -> clear the state, so the next incident alerts like new

Signatures must describe the problem, not the moment. Do not include the timestamp of
the failure in the signature or every failed run becomes a fresh alert while the task keeps
failing every cycle.

Trap 3: watching only Task Scheduler

Half the jobs that "run themselves" are not scheduled tasks - they are SQL Agent jobs,
SSIS packages, cron-style loops inside services, or a script on another box. Task Scheduler
monitoring gives you a green light while the real job rots.

The trick that covers everything is a heartbeat file: one line appended by the job on
success, one configured maximum age by the watcher.

# at the end of ANY job, scheduled or not:
Add-Content -Path C:\Scripts\hb.txt -Value (Get-Date -Format o)

If the file is missing or older than N minutes, alert. That converts "is my job alive?"
into a filesystem check that works for anything that can write a file.

What I run in production

After getting tired of rebuilding this per server, I packaged it as TaskWatch - a local,
subscription-free watchdog:

FAIL - watched task exited non-zero, exit code in the alert
MISSED RUN - "must run every 25 hours" exceeded
DISABLED / MISSING - someone turned your backup task off or deleted it
HEARTBEAT STALE - the heartbeat trick, automated
alerts via SMTP email, a Teams/Slack-style webhook, or the local log
an HTML status page per machine, one bookmark
one alert per problem, re-reminder after 24h, auto-clear on recovery
nothing leaves your machine: no cloud, no account, no telemetry

One-command setup registers it as its own scheduled task every 5 minutes, and it can send
you a test email during install so you know alerts work before you need them:

.\Install-TaskWatch.ps1 -WatchList 'NightlyBackup','SqlMaintenance' -SmtpServer smtp.example.com -From tw@example.com -To you@example.com

The full version is $15, one-time, no subscription
(30-day refund): xennedelan.gumroad.com/l/taskwatch

Free sample

I kept a free, MIT-licensed version for people who just want the report. It prints every
task that failed on the machine in the last 24 hours with exit codes, and exits 1 if
anything failed - so you can drop it into any existing alerting that understands exit codes:

git clone https://github.com/OpsKit-Dev/powershell-admin-scripts
powershell -ExecutionPolicy Bypass -File .\powershell-admin-scripts\TaskWatch\TaskWatch-mini.ps1

TaskWatch-mini.ps1 on GitHub

10 PowerShell scripts that catch Windows server problems before your users do - the scripts TaskWatch tells you to go run: disk cleanup, backup rotation, service watchdog, TLS expiry checks and more (OpsKit, $7)
Offboarding in PowerShell - the checklist I run when someone leaves - AD user offboarding ($2)

If TaskWatch saves you one "why is the export missing" conversation, it has paid for itself
several times over.

Disk cleanup with PowerShell: an age-gated script that shows its work before deleting anything

OpsKit — Wed, 07 Oct 2026 09:01:51 +0000

Temp folder cleanup is the kind of task everybody does by hand once, gets uncomfortable with, and then automates badly. The uncomfortable part is the three-week-old .part download sitting in someone's temp folder, or the log file that's still being written to — scripts that just do Remove-Item $env:TEMP\* don't care. They'll eat it.

Here's the cleanup script I actually run, and the three rules that make it safe enough to schedule.

Rule 1: never delete by age alone, always by last-touched age

The failure mode of naive cleanup isn't deleting too much — it's deleting something live. A file's creation date tells you nothing; a file being written to right now still has a creation date from three weeks ago if the folder was restored from backup.

What matters is last write time: if a file hasn't been touched in 3+ days, nothing has it open, nothing is appending to it, and nobody is actively using it. The script's -MinFileAgeDays parameter (default 3) filters everything through that check before a single file is considered:

$MinFileAge = (Get-Date).AddDays(-$MinFileAgeDays)
$targets | Where-Object { $_.LastWriteTime -lt $MinFileAge }

Raise it to 7 or 14 on busy servers. On a terminal server with users in session all day, that one number is the difference between a maintenance window and an incident.

Rule 2: -WhatIf has to mean something

PowerShell's SupportsShouldProcess attribute gives you -WhatIf and -Confirm for free, but only if you route every destructive call through ShouldProcess. The script does:

if ($PSCmdlet.ShouldProcess($file.FullName, "Remove (age $([math]::Round($age)) days)")) {
    Remove-Item -LiteralPath $file.FullName -Force -ErrorAction SilentlyContinue
    $freed += $file.Length
}

Run it once with -WhatIf and you get a complete preview — full paths, ages, counts — with zero deletions. It's a dry run you can paste into a change ticket as evidence of what would happen.

Rule 3: the script reports, it doesn't just delete

A cleanup that leaves no trace is a cleanup nobody can audit. Each run appends a line to %ProgramData%\OpsKit\disk-cleanup.csv:

Timestamp, Host, FreedMB
2026-10-08 03:14:02, WEB01, 812.4

Five weeks later, when someone asks why disk space jumped on Tuesday, the answer is one Import-Csv away. It also gives the script a natural heartbeat — an empty CSV section means the scheduled task stopped running, which you notice before the disk fills up.

What it actually cleans

User temp folders ($env:LOCALAPPDATA\Temp) for every profile on the box — not just the currently logged-in one
System temp ($env:windir\Temp)
Windows Update download cache ($env:windir\SoftwareDistribution\Download) — usually the biggest single win after a patch cycle, and safe to clear when the update service isn't mid-install
Old logs in paths you configure, age-gated the same way

.\disk-cleanup.ps1 -WhatIf                  # preview, delete nothing
.\disk-cleanup.ps1 -MinFileAgeDays 7        # only files idle a week
.\disk-cleanup.ps1 -MinFileAgeDays 3 -KeepDays 30  # logs: age-gate 3, retention 30

Try it before you trust it

disk-cleanup.ps1 is one of two scripts I keep MIT-licensed and free in the powershell-admin-scripts repo — source visible, no account, no telemetry. The companion there is ssl-expiry-check.ps1, which catches expiring certificates before your users do.

The full kit — backup rotation, service watchdog, event-log alerting, inventory export, share and password audits, patch reporting, and the user-offboarding checklist — is $7 on Gumroad with a 30-day refund. If offboarding is the only thing you need, the standalone script is $2.

Related: How to get an email when a Windows scheduled task fails - the watchdog I run over exactly these kinds of jobs (TaskWatch, free mini sample).

Offboarding in PowerShell: the checklist I run when someone leaves

OpsKit — Wed, 07 Oct 2026 08:39:13 +0000

Someone hands in their notice and IT gets one chance to get the offboarding right. Miss a step and you're explaining to security why a terminated employee's account still resolved Kerberos tickets three weeks later.

Here's the checklist I run, with the PowerShell for every step that can be automated — and an honest note about the steps that shouldn't be.

1. Disable the account (not delete)

Disable-ADAccount -Identity $user

Deleting breaks audit history and exchange artifacts you still need. Disable, and let your 30-day cleanup process delete later.

2. Kill the password now

Disabling stops interactive logon, but you also want the credential itself dead:

Set-ADUser -Identity $user -Replace @{ pwdLastSet = '0' }

pwdLastSet = 0 marks the password as needing a change at next logon — which effectively means the old password is done. Services still running as that user will fail loudly instead of silently continuing.

3. Terminate active sessions

Leaving a disconnected RDP session alive means a profile hive stays locked and scheduled tasks may keep running:

Get-Process -ComputerName $env:COMPUTERNAME |
    Where-Object { $_.UserName -like "*\$($user.SamAccountName)" } |
    Stop-Process -Force

Do this after disabling the account, and do it on every box your jump-host inventory knows about — not just the one you remember.

4. Archive the home directory before anyone empties it

$dest = "E:\offboarding\$($user.SamAccountName)-$(Get-Date -Format yyyyMMdd)"
& robocopy.exe $user.HomeDirectory $dest /E /R:1 /W:1 /NP

robocopy exit codes 0–7 are success — check for >= 8 before you let anything claim the copy worked. Archive first, remove access second. The order matters exactly once, and it matters a lot.

5. Write the audit trail while you do it

Every action above appends one row:

Timestamp | Ticket | Operator | User | LastLogon | Actions | HomeBackup

When security asks "when exactly did we cut off jsmith?", the answer should be a Select-String, not archaeology across four consoles.

6. The parts that must stay manual (on purpose)

Mailbox delegation and forwarding, distribution-group membership, VPN certificates, SaaS SSO apps, badge access — these live in systems with different owners and different blast radii. My script deliberately prints them as a to-do list instead of silently automating them:

Manual follow-ups: mailboxes/distribution groups, VPN, SaaS SSO, badge - not automatable here.

Automating revocation in a system you can't verify is how you get a "why did the CEO lose email" ticket.

The script

Steps 1–5 are one command with -WhatIf support and ConfirmImpact = High (you get prompted before anything changes):

.\user-offboarding.ps1 -SamAccountName jsmith -Ticket INC-1042 -HomeDirBackup E:\offboarding

Free first: two scripts from the kit (disk cleanup + TLS expiry, MIT) in the powershell-admin-scripts repo
Just the offboarding script: $2 — OpsKit Offboard
All ten admin scripts (cleanup, backups, watchdog, certs, alerts, inventory, share/password audits, patch report, offboarding): $7 — OpsKit

Both are instant download with a 30-day refund. (Disclosure: those are my products — the snippets above work standalone if you'd rather assemble it yourself.)

What's step 7 on your offboarding checklist? Mine's usually "find out which service account was using their laptop."

Related: How to get an email when a Windows scheduled task fails - the watchdog I run over exactly these kinds of jobs (TaskWatch, free mini sample).

10 PowerShell scripts that catch Windows server problems before your users do

OpsKit — Wed, 07 Oct 2026 08:09:34 +0000

Every Windows admin eventually writes the same five scripts from scratch: clean the temp folders, rotate the backups, watch the services, check the certificates, and offboard someone who left. Then the server gets rebuilt, and you write them again.

I got tired of that loop and packaged the ten scripts I kept re-writing into one small kit. Here are five of them with the part that actually matters — the logic, not the boilerplate — plus what each one has caught in practice.

1. Disk cleanup that tells you what it freed

The usual trap: Remove-Item -Recurse on C:\Windows\Temp while Windows Update is mid-download. Age-gate the files instead:

$cutoff = (Get-Date).AddDays(-$MinFileAgeDays)   # default 3 days
$files = Get-ChildItem -Path $dir -Recurse -File -Force -ErrorAction SilentlyContinue |
    Where-Object { $_.LastWriteTime -lt $cutoff }

Run it with -WhatIf first, then check the CSV: every run appends Timestamp, Host, FreedMB. On a terminal-server farm this is usually 4–10 GB per box on the first pass, then a few hundred MB a week.

2. Certificate expiry before the 3 a.m. page

Nobody notices the TLS cert until the webhook stops firing. A raw check needs no modules:

$ssl = New-Object System.Net.Security.SslStream($tcp.GetStream(), $false, { $true })
$ssl.AuthenticateAsClient($host)
$days = ([datetime]$ssl.RemoteCertificate.NotAfter - (Get-Date)).Days

Wire it to a host list, make it exit 1 when anything is under 30 days, and drop it in Task Scheduler. It has never been the interesting part of anyone's job, and it is always the thing that pages you.

3. A watchdog with a restart cap

Restart-Service in a loop is how you turn a 5-minute outage into a restart storm. The cap is the point:

$restartsToday = @(Import-Csv $LogPath |
    Where-Object { $_.Service -eq $name -and $_.Action -eq 'Restarted' `
                   -and [datetime]$_.Timestamp -ge (Get-Date).Date }).Count
if ($restartsToday -ge $MaxRestartsPerDay) { Write-Log $name 'Suppressed'; continue }

Three restarts and then it stops touching the service and writes Suppressed to the log. A dead service that stays dead is a signal; a service in a crash loop that you keep poking is noise.

4. Share permissions: find the `Everyone` group

if ($leaf -eq 'Everyone' -and $rule.FileSystemRights -match 'FullControl|Modify') {
    $flag += "RISK: $identity -> $perms"
}

Run against Get-SmbShare on every file server and you will, statistically, find at least one share where someone granted Everyone FullControl "temporarily" in 2019. The audit CSV gives you the share path and the exact ACE, so the remediation conversation is short.

5. Offboarding that leaves a trail

Disabling the account is the easy 10%. The parts people forget:

Set-ADUser -Identity $user -Replace @{ pwdLastSet = '0' }   # password dies with the session
# kill the user's processes, robocopy the home dir to an archive, append one audit line:
# Timestamp | Ticket | Operator | User | LastLogon | Actions | HomeBackup

Every action writes one CSV row with the ticket number, so when someone asks "when exactly did we cut off jsmith?", the answer is a Select-String, not archaeology.

What ties them together

Three rules, applied everywhere:

-WhatIf before destructive. Every script that deletes, disables, or restarts supports SupportsShouldProcess.
CSV audit for every mutation. If it changed state, it logged a timestamped row to %ProgramData%\OpsKit\.
No obfuscation, no agents, no telemetry. Plain commented PowerShell you can read before you run it — which is the only kind of script worth putting on a production box.

The honest pitch

These ten — cleanup, backup rotation, service watchdog, cert expiry, event-log alerting, inventory export, share-permission audit, password-age audit, patch reporting, and offboarding — are the pack I'd have bought years ago instead of re-writing. Two ways in: the whole kit is $7 (OpsKit — 10 Windows Server Admin PowerShell Scripts), or if offboarding is your only pain point, the offboarding script alone is $2 (OpsKit Offboard). Prefer to try first? disk-cleanup and ssl-expiry-check are MIT-licensed and free in the powershell-admin-scripts repo. Everything is tested by dry-run and live execution, 30-day refund if it's not for you.

(Full disclosure: yes, that's my product. The five scripts above work standalone if you'd rather copy them — no hard feelings.)

Speaking of failing quietly: knowing when one of these jobs dies at 3 a.m. is the other half of the problem. I wrote How to get an email when a Windows scheduled task fails (including the LastRunTime PowerShell bug that will page you for nothing), packaged it as TaskWatch - $15, local, no subscription, and kept a free failure-report sample in the repo (TaskWatch-mini.ps1).

What would you add? The one I'm still missing is a DNS stale-record sweeper.