Questions, answered

Your first machine is free forever. Beyond that: Pro $199/year for up to 10 machines, Business $499/year for up to 50, and MSP $999/year for unlimited machines across client sites. Every install begins with a 30-day full-featured trial, so you can prove it in your own environment before paying. See pricing.

Nothing stops. Every agent you already have keeps being monitored, restarted, and alerted on. An expired license only prevents registering new machines beyond your tier. We think monitoring that goes dark over a billing hiccup is unforgivable.

Yes. Use the 30-day trial first, that's what it's there for, but if you buy and change your mind, email us and we'll refund it. The full terms are on the refund policy page.

One registered agent, i.e. one Windows machine reporting to your hub. A domain controller, a receptionist's PC and a Hyper-V guest all count exactly the same: one each. The hub itself only counts if you also install an agent on it to watch its own services. Users, checks, alerts and events are unlimited on every tier.

Windows edition makes no difference to what you pay: we don't price server and client operating systems differently, and physical and virtual count the same. The binding wording is in the licence agreement, section 1.

No. Your hub, its database, your rules, history and every already-registered machine stays exactly as it is. Renewal governs one thing only: adding machines beyond your tier.

Yes. The hub is fully self-hosted and license keys are verified offline with embedded public-key cryptography. No monitoring data leaves your network. Ever. Stoker sends no telemetry, no usage reports, and no diagnostics.

There is one optional outbound call: an opt-in daily check against a public URL to see whether a newer version is out. It's off by default, and when enabled it sends nothing about you or your machines, just asks "what's the current version?". Leave it off and Stoker is completely silent to the outside world.

Modern 64-bit Windows (Windows Server 2019+ or Windows 10/11 recommended) for both hub and agents. Stoker is not server-only: agents run just as happily on desktops, laptops, VMs, kiosks and POS terminals. No runtimes or databases to install. Everything ships self-contained.

Yes. HTTP uptime checks run from the hub with status, keyword and latency validation, plus TLS certificate expiry warnings before the renewal outage call comes in.

In a SQLite database on your hub server. Back up one file and you've backed up Stoker.

A scheduled task can't detect a service that is running but hung, can't measure CPU or memory against a threshold over a breach window, can't stop itself when a service is crash-looping, can't be reconfigured across a fleet from one screen, and can't tell you what happened last week. Stoker does all of those, and setup is minutes rather than an afternoon of scripting you then own forever.

No, but most people will want to. Each agent enforces its own service rules directly on the machine it runs on (watching, restarting, and applying the circuit breaker) whether or not a hub is reachable. So a single machine can run the agent by itself as a lightweight auto-restart watchdog.

What the hub adds is everything central: the dashboard, email and webhook alerts, website and TLS-certificate checks, the searchable event history, and configuring rules for your whole fleet from one screen. A standalone agent does none of those; it just keeps its own services running and logs to the Windows Event Log. Since the hub is free for your first machine, there is rarely a reason to skip it.

Agents carry on protecting their machines. The last rules they received are cached locally and survive reboots, so watching, restarting and the circuit breaker all continue; the agents simply can't report in or receive rule changes until the hub is reachable again. The license and hub add central visibility and management. They never gate the protection happening on the box.

Put your rules in the Agent:Services array of the agent's appsettings.json, then restart the Stoker Agent service. Each rule names a Windows service and its thresholds:

"Agent": {
  "AgentId": "web-01",
  "Services": [
    {
      "Name": "W3SVC",
      "CpuLimitPercent": 90,
      "MemoryLimitMb": 2048,
      "BreachSeconds": 60,
      "RestartIfStopped": true,
      "CooldownSeconds": 120,
      "MaxRestartsPerHour": 3,
      "RestartTimeoutSeconds": 30
    }
  ]
}

These local rules are the fallback the agent runs until (and unless) a hub sends it managed rules, so they are exactly how you configure air-gapped machines. One note: the agent is built to report to a hub, so if there is no hub it will still try to reach Agent:HubUrl and log a harmless "could not reach hub" line each cycle, but enforcement continues either way. Full field reference is in the docs.

Yes, seamlessly. Point the agent at a hub (set Agent:HubUrl and Agent:ApiKey, or just re-run install-agent.ps1 with -HubUrl/-ApiKey) and it appears on the dashboard within seconds. The moment you save rules for it there it becomes hub-managed and the dashboard is the source of truth; until then it keeps running its local appsettings.json rules. Click Stop managing from the hub any time to hand control back to those local rules.

Each agent presents an API key you generate (and can revoke) in the dashboard. Keys are stored hashed on the hub. Agents initiate every connection themselves and fetch their configuration over it, so monitored machines never open an inbound port and nothing can connect in to them.

No. A cooldown enforces a minimum gap between restarts of the same service, and a restarts-per-hour circuit breaker suspends automation entirely once it trips, raises a Critical alert, and waits for a human. Automation resumes when the hour window clears. Details in the service rules docs.

Create a maintenance window. It can run once, or on a schedule — every Sunday at 3 a.m., the day after Patch Tuesday, the last Saturday of the month — and it can cover one machine, everything, or every machine carrying a tag such as client:northgate, so a whole site goes quiet together. While it is open Stoker holds those machines' notifications and tells their agents to pause auto-restart so they don't fight the box you're patching.

What it doesn't do is stop watching. When the window closes, Stoker checks that every service running before it opened is running again and raises a critical alert naming anything that isn't — so a server that reboots and comes back without SQL Agent reaches you that night, not when the customer rings in the morning. The event log records the whole time, and the Maintenance page shows what went down, for how long, and what came back.

No. A window can be extended from the dashboard while it is open, and the agent takes a local command you can drop into whatever patching tool you already run: Stoker.Agent.exe maintenance start --minutes 120 before the run and maintenance stop after it. That works even when the hub itself is unreachable, which during a site-wide patch run it often is, and the hub mirrors the window so the alerts are muted centrally too.

Yes. Create as many users as you need, each an admin (full control) or read-only (sees the dashboard, checks, events and history, changes nothing). Perfect for on-call staff or a view-only screen on the wall. No shared logins.

Windows tags files downloaded from the internet, and stricter execution policies then refuse to run the scripts. Easiest fix: right-click the downloaded zip → Properties → tick Unblock → OK, then extract. More options are in the troubleshooting docs.

Check the agent service is running (Get-Service StokerAgent), that the HubUrl is reachable from that machine, and that the API key wasn't revoked. If you're on the free tier or an expired license, machines beyond your tier are declined and the hub logs an event saying so. The full checklist is in the docs.

Yes, two supported ways: the hub serves HTTPS itself from a certificate in the machine store, or you terminate TLS at IIS/Caddy/Nginx in front of it. Both are walked through in HTTPS / TLS.

Run the newer installer over the old one: double-click the new MSI, or unzip the new version and re-run the script. The hub database (rules, users, event history) lives in C:\ProgramData\Stoker and is never touched by the installer, and each app's appsettings.json is preserved in place, so your hub URL, API key, port, cert and every setting all carry over untouched. Hard-refresh the dashboard once (Ctrl+F5) if your browser cached the old stylesheet.