Know it's broken before your customers do.
Uptime, scheduled jobs, DNS, and SSL — the four checks a small team actually needs, in one tool. When one fails, it doesn't just page you: it opens an incident and updates your status page.
Monitoring is the trigger, not the destination. The alert is where every other tool stops. It's where this one starts.
Four checks. The ones that actually matter for a small team.
Not fifty monitor types you'll never configure. The four that tell you something's wrong before a customer does — each one wired to open an incident, not just send a ping.
Is your site responding, and how fast? HTTP checks on the interval you set.
Did your scheduled job actually run? The reverse of uptime — for cron and sync processes.
Did a record change when nobody meant it to? Per-record snapshots, with change alerts.
Is your certificate about to expire? SSL, WHOIS, and DNS rolled up per domain.
Uptime monitoring
HTTP and HTTPS checks on the interval you choose — and a failure that turns into an incident, not just an email.
Point a check at any URL. GET, POST, or HEAD; the frequency you want, from every 30 seconds to once a day. We resolve DNS, open the connection, run the request, and time every phase of it — DNS, connect, time-to-first-byte — so when something slows down you can see where.
A single network blip shouldn't wake you. When a check fails, it re-checks at a faster confirmation interval to confirm the failure is real before anything happens. Only once it's confirmed past your threshold — a number of consecutive failures you set per component — does an incident get created automatically. When the check recovers, the incident resolves itself.
You can mark a check "degraded" rather than "down" when it's just slow: set a response-time threshold, and a check that succeeds but crawls gets flagged before it falls over completely.
Heartbeat monitoring for cron jobs and scheduled tasks
The reverse of uptime: the job should check in on a schedule, and you hear about it when it doesn't.
Uptime monitoring asks "is this URL responding?" Heartbeat monitoring asks the opposite question: "did the thing that's supposed to run actually run?" Your nightly backup, your hourly sync, the cron job that emails invoices — they should each tell you they finished. When one goes quiet, that's the signal.
Give us a schedule — a simple interval, or a full cron expression — and we hand you a ping URL. Your job calls it on success: one line at the end of the script, or a curl after the command. Miss the window plus a grace period you set, and an incident opens automatically. The next time the job runs, the incident resolves.
Because it's a plain HTTP ping, it works from anywhere your job already runs — including behind a firewall, where a poll-based monitor can't reach. Lock the ping endpoint down with an API key if you want to, or leave it open for a job that can't carry a secret.
DNS monitoring
Watch the records that matter, and hear about a change you didn't make.
A changed DNS record is the kind of thing you find out about the hard way — email stops arriving, or a subdomain starts resolving somewhere it shouldn't, and you spend an hour ruling out everything else first. DNS monitoring watches the records that matter so the change itself is the alert.
We check the record types you care about — A, AAAA, MX, NS, TXT, CAA, CNAME — per hostname, and keep a history that only records an entry when something actually changes. So the timeline is signal, not noise: every row is a real change, with a before and after.
Alerting is opt-in, per record. Leave a record advisory and it's just visible in the UI. Turn on change alerts for the ones that matter — your MX record, your CAA policy — and a change you didn't make opens an incident. Turn on error alerts and you hear about it when a lookup starts failing entirely.
SSL certificate monitoring, as part of one domain check
One check per domain covers three things you'd otherwise track in three places: certificate expiry, domain registration expiry, and DNS.
Certificates expire on a Sunday. Domains lapse because the renewal email went to an inbox nobody reads. These aren't outages you can engineer your way out of — they're calendar problems, and a calendar reminder is exactly the thing you'll snooze. So we don't do reminders. We do an incident, with lead time.
A domain check is keyed on your domain and rolls up three facets in one place:
- SSL — the TLS certificate at each hostname you list, apex and subdomains. Track days-until-expiry and get an incident before the cert actually expires, not after a customer's browser throws a warning.
- WHOIS — your domain's registration expiry, so the domain itself doesn't lapse out from under the product.
- DNS — the record sets from the section above, watched per hostname with the same change history and opt-in alerts.
Each facet rolls up to a single status for the domain. Severity escalates as things get worse — a warning becomes critical becomes expired — but never quietly downgrades. One check, three of the things most likely to take you down without a single line of code changing.
Got a job we can't see from the outside? Use the API.
Some things only your own code knows — like whether the job that should've run at 2am actually did.
- Heartbeat pings for "did it run?" — your job calls a ping URL on success, and a missed ping opens an incident, exactly like the scheduled-job monitors above. Lock it with an API key or leave it open.
The alert is where other tools stop. Here it's the start.
Every check on this page does the same thing when it fails: it opens an incident. And the incident is wired to everything else.
A monitor firing is only useful if it kicks off the work that follows. Most tools hand you the alert and leave the rest to you — at 3am, you still open the status tool, write the update, acknowledge the page, and reply to the customer who already emailed. That's four tools and four context-switches for one problem.
Here it's one chain, and most of it is automatic:
-
1
A check fails.
Confirmed past your threshold — not a single blip.
-
2
An incident opens.
Automatically, with the source check linked, at the severity you set.
-
3
Your status page updates.
If the affected component is public, your customers see it — without you posting a thing.
-
4
Related tickets show the link.
When a customer's already reported it, support sees the active incident on the ticket.
When the check recovers, the incident resolves itself and the status page clears. The only time you have to touch it is when a human judgement call is actually needed — which is exactly when you'd want to.
What we don't monitor
We do the four checks a small team needs to know something's wrong. We don't do the deep observability you'd reach for to figure out why — and we'll point you at the right tool rather than pretend we cover it.
Not error tracking or APM. When you need stack traces, slow-query breakdowns, and per-request traces, that's Sentry, Datadog, or similar. We tell you the endpoint is down; they tell you which line of code did it.
Not infrastructure metrics. CPU, memory, disk, container health — that's your cloud provider's dashboards or a metrics platform. We watch the surfaces your customers touch, not the boxes underneath.
Not synthetic browser testing. Full user-journey scripts that click through a checkout flow are a category of their own. Our uptime checks are HTTP-level — fast, cheap, and enough to know the door's open.
Wire up your monitors. Get in early.
Private beta in a few weeks. I'm letting people in a small group at a time so I can actually work with each of you — including which checks are worth running and which thresholds actually make sense for a team your size. The earliest customers shape what gets built next.
Drop your emailDirect email from Rob when your slot's ready. No drip sequence.