SteadyMonitor

Know it broke before they tell you.

SteadyMonitor watches your sites, APIs, DNS and ports from agents you run yourself — inside your network, at the edge, or both. When something stops answering, you hear about it in seconds.

Start monitoring free See pricing

Free tier, no card. Uses your SteadyCircuit account.

Watch from where it matters

Run agents in your own datacentre, office or cloud. A check runs on every agent that matches it, so you see the outage that only affects one region.

More than a ping

HTTP, DNS, TCP and ICMP, with status codes, body matching, expected IPs and TLS expiry warnings before the certificate takes the site down with it.

Prove the firewall works

Negative checks alert when something answers that should not — a port that ought to be closed, an admin path that ought to be unreachable from outside.

Pricing

Start free. Move up when you outgrow it.

Every plan is a monthly budget of check-runs. One run is one check, executed once, from one agent. Spend it on more things watched, watched more often, or watched from more places — whichever you need.

Feature comparison of the Free, Starter, Growth and Business plans
Feature Free A handful of things, watched properly.

£0 /mo

Free forever

 Starter One product you cannot afford to have down.

£6 /mo

Billed monthly

 Most popular Growth Several environments, several people on call.

£19 /mo

Billed monthly

 Business A real estate, watched from everywhere.

£59 /mo

Billed monthly
Check-runs Per month, across every check and agent
Fastest check interval 3 min 60s 30s 15s
2 public, no private agents 4 public, 1 private 4 public, 3 private 4 public, 10 private
History retained 7 days 30 days 60 days 90 days
Users 1 3 10 Unlimited
Not included Included Included Included
Alert channels Email, Telegram and webhooks — on every plan
Email Telegram Webhook
Email Telegram Webhook
Email Telegram Webhook
Email Telegram Webhook
Status page Publish the checks you choose, to anyone, with no sign-in Not included Included Included Included
Custom domain Serve that page on your own hostname Not included Included Included Included
Incidents Coming soon Group related alerts, post updates, publish a timeline Not included Included when it ships Included when it ships Included when it ships
Get started Choose Starter Choose Growth Choose Business

Prices in GBP, excluding VAT, billed monthly. Unused check-runs do not roll over. On the free plan checks pause when the budget runs out and resume on the first of the month; on paid plans they keep running, and anything past the included block is billed at your plan's per-million rate.

Public and private agents

A check runs on every agent that matches it. Where the agent sits decides what it can reach.

Public agents — we run them

Ours, in our regions. They reach your service the way the public internet does — so they answer “can a customer in Frankfurt load this?”, and equally “can a stranger reach the database?”

Public agents checking what must answer and what must not Agents in London, Frankfurt and New York check across the public internet that www.example.com answers, and that port 5432 on the same host does not. Our regions London Frankfurt New York from outside www.example.com must answer 203.0.113.10:5432 must not answer

Private agents — you run them

Yours, inside your network. They reach what has no public address at all — and can prove a port that ought to be closed really is.

A private agent checking inside your network An agent you run inside the 10.0.0.0/8 network checks that Postgres at 10.0.4.12 port 5432 and staging.internal answer, and that the payments segment at 10.9.0.0/24 does not answer from here. It also reaches out to www.example.com. Your network · 10.0.0.0/8 Your agent 10.0.4.12:5432 staging.internal 10.9.0.0/24 must not answer www.example.com …and out, too

Most people want both. Public agents catch the outage your customers would see; private agents catch the one they would not — a replica that stopped replicating, a certificate on an internal service, a firewall rule that quietly stopped applying. Every plan includes public agents; private agents start on Starter.

 

Every agent that runs a check spends a run. Watching the same thing from more places costs more runs, so the budget buys either breadth or frequency — your call.

Rounded down, and assuming every check runs on every agent you have switched on. Point a check at a subset of agents and it costs proportionally less.

Negative checks

An ordinary check alerts when something stops answering. A negative check alerts when something starts.

Point one at a port that ought to be closed from outside — your database, an admin path, a management interface. The same check runs on a schedule like any other. Only the healthy answer is inverted: silence is a pass.

The rule is holding

The agent knocks from the public internet. The firewall drops it. Nothing answers, which is exactly what you wanted — the check passes and stays quiet.

A blocked probe, which is the passing result An agent on the public internet probes port 5432. The firewall blocks it, nothing answers, and the negative check passes. Our agent outside firewall dropped postgres 10.0.4.12:5432

No answer → healthy

The rule is gone

Someone widens a security group, a rule is reordered, a service rebinds to every interface. The knock gets through and the database answers a stranger. You are told.

A probe that got through, which raises the alert The firewall rule is missing, so the agent's probe reaches port 5432 and Postgres answers. The negative check fails and alerts. Our agent outside firewall rule missing postgres answers 10.0.4.12:5432

Answered → alert

Nothing is down when this fires. That is the point. Ordinary uptime monitoring cannot see a firewall rule that quietly stopped applying, because every service it watches is still answering perfectly. A negative check is the only one that treats a successful connection as the failure — and it keeps testing the rule long after whoever wrote it has forgotten it exists.