Automated Windows Server Backup Alerts: Setup Guide

Windows Server Backup writes failure events to the Event Log every time a job breaks. This guide walks you through reading those events, writing a PowerShell notification script, and wiring it to Task Scheduler so an email or SMS fires the moment a backup fails – before you discover the gap during a restore.

Most backup failures go unnoticed until someone needs to recover a file. By the time that happens, days or weeks of backup jobs have already failed silently. The steps below close that gap with a native Windows alert system that costs nothing extra and runs without third-party agents.

Step 1 – Identify Backup Failure Events in Windows Event Logs

Open Event Viewer by running eventvwr.msc and expand the Application and System logs. Windows Server Backup writes its events under the source Microsoft-Windows-Backup. The event IDs that signal a failed or incomplete backup job are 5 (backup failed), 517 (backup started but did not complete), 521 (cannot write to backup location), and 546 (backup job was not configured correctly). Search both the Application and System logs for these IDs to confirm your server is generating them before building the alert.

Step 2 – Create a Custom View for Backup Failure Events

In Event Viewer, right-click Custom Views in the left pane and select Create Custom View. On the Filter tab, set the event log to Application and System, paste the event source Microsoft-Windows-Backup, and enter the failure event IDs (5, 517, 521, 546) in the Includes/Excludes field. Name the view Failed Windows Backups and click OK. This view becomes the trigger anchor for the Task Scheduler attachment in Step 4 – every new entry that matches automatically surfaces here.

Step 3 – Write the PowerShell Notification Script

Save the script below as C:\Scripts\BackupAlert.ps1. After saving, restrict write access on that folder to Administrators only so the script cannot be tampered with by a standard user account.

param(
    [string]$EventId = "",
    [string]$EventMessage = ""
)

$smtpServer   = "smtp.yourdomain.com"
$smtpPort     = 587
$smtpFrom     = "alerts@yourdomain.com"
$smtpTo       = "admin@yourdomain.com"
$smtpUser     = "alerts@yourdomain.com"
$smtpPass     = ConvertTo-SecureString "YOUR_APP_PASSWORD" -AsPlainText -Force
$credential   = New-Object System.Management.Automation.PSCredential($smtpUser, $smtpPass)

$subject = "BACKUP FAILURE on $env:COMPUTERNAME"
$body    = "A Windows Server Backup failure was detected.`n`nEvent ID: $EventId`nDetails: $EventMessage`nTime: $(Get-Date)"

try {
    Send-MailMessage -SmtpServer $smtpServer `
        -Port $smtpPort `
        -UseSsl `
        -Credential $credential `
        -From $smtpFrom `
        -To $smtpTo `
        -Subject $subject `
        -Body $body

    # Optional: send to SMS via email-to-SMS gateway (e.g., 5551234567@txt.att.net)
    # or replace with a Twilio REST call here

    Add-Content -Path "C:\Scripts\BackupAlert.log" -Value "$(Get-Date) - Alert sent for Event ID $EventId"
}
catch {
    Add-Content -Path "C:\Scripts\BackupAlert.log" -Value "$(Get-Date) - FAILED to send alert: $_"
}

To route alerts to SMS without a dedicated API, replace the $smtpTo value with your carrier’s email-to-SMS gateway address (for example, 5551234567@tmomail.net for T-Mobile). For higher reliability, swap that line for a Twilio REST call using Invoke-RestMethod with your Twilio account SID and auth token.

Expert Take

SMTP authentication is where this setup breaks most often. Microsoft 365 deprecated basic authentication for SMTP relay in 2022, so a username-and-password credential against smtp.office365.com no longer works by default. You need either an app password generated from an account with multifactor authentication enrolled, or a full OAuth2 flow using a registered Azure app. Before you wire the Task Scheduler trigger, send a test email from PowerShell manually and confirm the relay accepts it. If your tenant uses Conditional Access policies, the service account running this script also needs to be in an exclusion or on a compliant device – confirm with your Microsoft 365 admin before assuming relay permissions are open.

Step 4 – Attach a Task Scheduler Trigger to the Failure Event

In the Custom View you created, right-click any existing backup failure event and select Attach Task To This Event. The Task Scheduler wizard opens with the event source and event ID pre-populated. On the Action screen, choose Start a program and enter:

Program: powershell.exe
Arguments: -ExecutionPolicy Bypass -NonInteractive -File "C:\Scripts\BackupAlert.ps1"

Under the General tab, configure the task to run under a dedicated service account with the minimum permissions required – local log-on rights and read access to Event Viewer. Do not run this task under a domain admin account. Set it to run whether the user is logged on or not, and tick Run with highest privileges only if your SMTP relay requires it. Save the task and note its name for Step 5.

Step 5 – Test the End-to-End Alert Flow

Simulate a backup failure by temporarily pointing Windows Server Backup at an invalid target – a disconnected USB label or a nonexistent UNC path – and running a manual backup job. Confirm the expected event ID appears in your Custom View, then watch Task Scheduler history to verify the task fired. Check C:\Scripts\BackupAlert.log to confirm the script executed and the alert sent successfully.

Run this test three times to cover the scenarios that matter: during business hours with someone watching, overnight with no one logged in, and with SMTP temporarily unavailable (disable the relay or enter the wrong port, then re-enable). Each test should produce a clear log entry. If the overnight test does not fire, the service account likely lacks the right to run tasks in a non-interactive session – revisit the task’s security settings.

Step 6 – Add Redundancy and a Heartbeat for the Alert System

A single SMTP relay is a single point of failure. Configure a secondary relay in the script using a try/catch that falls back to a different provider if the primary send fails. Document both relay credentials in your password manager and rotate them on the same schedule as your other service accounts.

Add a separate scheduled task that runs daily and sends a short “Alerting System Operational” email to your monitoring inbox. If that heartbeat email stops arriving, the alert system itself has broken – not just that no backups have failed. Name a specific person as the escalation owner for missed heartbeats and put that name in the heartbeat email body so anyone who sees the inbox knows exactly who to call.

For a broader look at how automated monitoring fits into a layered data protection strategy, see 10 Ways AI Automation Can Elevate Data Protection and Business Continuity.

Frequently Asked Questions

What event IDs signal a Windows Server Backup failure?

Four event IDs cover the failure scenarios you need to catch: 5 (backup job failed), 517 (job started but did not complete), 521 (Windows Server Backup cannot write to the backup location), and 546 (the backup job has a configuration error). Filter your Custom View on all four so a single missed event does not leave you with a silent gap in coverage.

What account permissions does the scheduled task need?

The task service account needs three things: the right to log on as a batch job (granted in Local Security Policy under User Rights Assignment), read access to the Application and System event logs, and network access to your SMTP relay. Create a dedicated service account rather than reusing an existing admin account – a scoped account limits the blast radius if the credential is ever compromised.

How do I send SMS without a dedicated API?

Every major US carrier provides an email-to-SMS gateway: messages sent to number@tmomail.net, number@txt.att.net, or number@vtext.com arrive as text messages. Set that address as the recipient in Send-MailMessage and your existing SMTP relay handles the delivery. The limitation is reliability – carrier gateways deprioritize email-to-SMS traffic, so for production alerting that must notify someone within minutes, a Twilio REST call via Invoke-RestMethod is more dependable and adds delivery receipts you can log.

How do I verify the alert system stays working over time?

The daily heartbeat task in Step 6 is your first line of verification. Beyond that, tracking the right backup health metrics tells you whether the entire chain – backup jobs, alert scripts, and escalation paths – is performing as designed. The 10 Metrics to Track for Effective Backup Verification post covers the specific numbers to monitor, including recovery point objectives, restore test success rates, and alert delivery latency. Review those metrics monthly and tie the heartbeat check to the same calendar item.