A .NET 10 Windows service checks every site each minute, applies one safe IIS recovery action after repeated failures, confirms the site is back and alerts the team in Microsoft Teams when it is not.
Starting point
The client runs a group of nopCommerce stores, on .NET 8 and .NET 9, spread across several Windows servers with IIS. When a site stopped, or its application pool stopped or became unhealthy, nothing noticed. The site stayed down until a customer or a member of staff reported it.
They wanted routine outages fixed automatically, without changing the nopCommerce code, without adding a health endpoint to every site and without paying for an external monitoring platform.
What we built
- Finds the IIS sites on each server by itself, from a JSON list, or both, and picks the right URL from each site’s bindings
- Requests every homepage every 60 seconds, with a timeout, a redirect limit, expected status codes and an optional content check
- Sorts each failure by type (DNS, certificate, connection refused, timeout, redirect, status or content)
- After 3 failures in a row, takes one recovery action: start the stopped site, start the stopped app pool, or recycle the site’s own app pool, then waits and checks again
- Never runs iisreset, restarts Windows, kills worker processes or recycles a shared app pool unless that is turned on
- Sends an Adaptive Card to Microsoft Teams when a site needs a person, with one alert per incident and a reminder every hour
- Pauses checks during maintenance or deployments when an app_offline.htm file or a maintenance lock file is present
Built for operations
- One state file per site, so incidents survive a service restart
- Alerts wait in an on-disk queue, so a Teams outage never stops monitoring
- Command-line tools to validate the configuration, list sites, check one site and send a test alert
- A self-contained MSI installer that runs silently, keeps the configuration through upgrades and needs no .NET install on the server
- Every release is built, tested, audited for vulnerable packages and published with SHA-256 checksums and an SBOM
Rollout
The rollout plan starts on one server with a handful of low-risk sites in audit-only mode, where the service reports but does not act. It then moves to all servers in stages.