Get paged when a Windows service stops. Point it at any service on any Windows server — a SQL Server instance, an IIS app pool's service, a vendor agent, your own background worker.
Start at Windows Services.
Already running the JAMS Agent? Then there's nothing to install. A server monitored for JAMS Scheduler can watch ordinary Windows services at the same time — it shows up in the server list here automatically. Skip to Choosing which services to watch.
How it works
A small Agent runs on the server as a Windows service. It checks the services you've chosen and reports their state back here. When one stops, the alert flow you've picked fires.
The Agent only ever reports. It reaches out to us; nothing needs to reach in. That means:
- No inbound firewall rules. No port to open, no address to publish.
- No credentials. It runs as
LocalSystemand reads local service state. You don't give it an account, and there's nothing stored on the server for someone to find. - Nothing to configure on the server. Which services to watch is decided here, not there — so changing your mind later doesn't mean touching the machine again.
Adding a server
- Go to Windows Services → Add a server. Give it a name you'll recognise in an alert at 3am — the machine name is usually right.
- You'll get a pairing token. Copy it now.
- Download the installer, run it on the server, and choose Windows Services only.
- Paste the token when asked. That's the whole setup.
The pairing token is shown once. We store only a hash of it, so we genuinely cannot show it again. If you lose it, add the server again and delete the one you couldn't pair — it's a minute of work, not a support ticket.
One Agent per server. The Agent watches the machine it's installed on. Monitoring five servers means five Agents and five tokens.
Choose "Windows Services only" unless the server also runs JAMS Scheduler. The other option additionally sets up job remediation, which needs a JAMS address it won't find.
Choosing which services to watch
Once a server has paired, use Discover services to have the Agent list every Windows service installed on it. Tick the ones you care about and pick the alert flow that should fire.
Discovery reads the live machine rather than a list you maintain, so a service added by a later software install shows up the next time you look — you don't have to remember to come back and register it.
Watch the service, not the software. Plenty of products install several services where only one matters, and some are meant to sit stopped. Ticking everything produces alerts nobody trusts, which is worse than monitoring nothing.
What "stopped" means, and what it doesn't
The Agent reports each watched service on a schedule. Two situations look similar on a dashboard and are treated very differently here:
| What happened | What you see |
|---|---|
| The service stopped, and the Agent said so | Stopped — and the alert fires |
| The Agent hasn't reported recently enough | Unknown, marked stale — no "stopped" alert |
A silent Agent is never reported as a stopped service. That distinction matters more than it looks: if a server is powered off, every service on it is technically not running, but we haven't observed them stopping — and a page saying "SQL Server stopped" when the truth is "we can't see the machine" sends somebody to fix the wrong thing.
Instead, an Agent that goes quiet raises its own alert saying exactly that. This is how a powered-off server surfaces.
Every service label shows the machine it's on in brackets, so two servers running identically-named services stay distinguishable in the list and in an alert.
Why an enabled monitor might page nobody
Monitoring can be switched on, services ticked, and the card looking healthy while the alert has nowhere to go. There are four ways in, and the page names whichever applies rather than leaving you to find out during an incident:
- The monitor has no alert flow chosen.
- The chosen flow was deleted.
- The chosen flow was deactivated.
- The flow has no recipient we can actually deliver to.
If you see one of those on the page, the monitor is running and no alert will reach anyone. Fixing it is picking a flow, or fixing the flow's recipients.
JAMS servers and Windows servers are listed separately
If you use both, the two live on separate pages (JAMS Scheduler and Windows Services) with their own alert flows and their own recipients.
That's on purpose: the person who should hear that a JAMS job failed is often not the person who should hear that a SQL Server service stopped. Keeping them apart means each alert reaches the team that owns it.
A single server can appear in both places. That's one Agent doing two jobs, not two installations.
Troubleshooting
The server never pairs. The token is scoped to this environment and this account, so a token minted here won't pair against a different one. Re-check that you pasted it whole — it's long.
A service shows "Unknown". The Agent hasn't reported recently. Check the Agent's own Windows service is running on that machine (it's listed under Services as the JAMS Agent), and that the server has outbound internet access.
Discovery returns nothing. Discovery is a request the Agent picks up on its next check-in rather than an instant answer, so give it a moment and reload. If it stays empty, the Agent isn't reporting — see above.
Alerts stopped arriving after a change. Check the alerting gaps above first; a deleted or deactivated flow is the most common cause and doesn't announce itself.
Related
- JAMS Scheduler — job failure alerts and remediation from the same Agent
- Runaway control — stop a flapping service from paging repeatedly
- Nobody got the SMS or call — when the alert fired but nobody heard it