Monitoring & Status
Know your site is down before your customers do
Watch websites, APIs, ports, certificates, DNS, cron jobs and your own servers — checked from Europe, North America and Asia-Pacific at once, so you see the outage your customers in Frankfurt hit even when it looks fine from Ashburn. A status only changes when enough regions agree, which is why you hear from us when something is actually wrong.
Free plan · No credit card · First monitor live in under a minute
- Checked from three continents
- One incident, not ten alerts
- Eleven things it can watch
- Straight into Slack, Jira or PagerDuty
Checked from everywhere, confirmed before you are woken
Every check runs from probes in Europe, North America and Asia-Pacific at the same time. One of them failing is not an outage — it is one probe having a bad second, and a monitoring tool that pages you for it teaches you to ignore it. So a status only flips when enough probes, in enough different regions, agree. You get the outage your customers actually hit, and you stop getting the ones they never noticed.
- Probes in Europe, North America and Asia-Pacific, on every check
- A status changes only when your threshold of probes — and of regions — agrees
- Per-region response times, so “it is slow in Asia” is a thing you can see
- Flapping is damped, so a service bouncing does not page you twelve times
https://api.northwind.com/v1/search
Checked from 3 regions · 2 probes must agree · 2 of 3 regions must agree
A status only changes when the thresholds above are met — which is why one region having a bad second never reaches you.
Eleven things it can watch, not just “is the site up”
A website answering 200 is the easy case. InfraNest also watches the things that break quietly: a cron job that stopped calling in, an API returning the wrong JSON field, a redirect that lost its destination, a certificate three days from expiry, a port that closed, a DNS record that stopped resolving — and the servers underneath, with CPU, memory, disk and services from the agent. It even watches other people’s status pages, so an outage at a provider you depend on reaches you without you refreshing theirs.
- Heartbeat monitors catch the cron job that silently stopped running
- API monitors assert on JSON fields, not just on the status code
- Server monitors report CPU, memory, disk, load and services
- Service-status monitors poll your providers’ own status pages for you
Then it asks for
A URL, and the status code you expect back
A URL, and the keyword to find in the response
A URL, and the final URL you expect to land on
A domain or IP, and the port
A domain, and how many days ahead to warn you
A domain, the record type, and the value you expect
A domain or IP address
A URL, plus assertions on the JSON that comes back
Nothing — it hands you a URL for your job to call
Which server, and which metric crosses which threshold
Which provider, and which of its components you depend on
One outage, one incident — not ten alerts
When the database goes, everything in front of it goes too. Most tools then page you once per check, and you spend the first ten minutes of an outage working out which alert matters. Tell InfraNest which monitors depend on which and it does that for you: the parent going down suppresses the children, so you get one incident naming the thing that actually broke, with a timeline you can add updates to. Planned work goes in a maintenance window and never reads as an outage at all.
- Declare what depends on what — a parent going down silences its children
- One incident with a timeline: detected, confirmed, updated, resolved
- Maintenance windows pause alerting and mark the work as planned
- Acknowledge or resolve from the alert itself, or from an automation
Which monitors depend on which is something you declare once, per monitor.
Where the alert goes is the whole point
An alert nobody sees is not monitoring. Send warnings to a Slack channel and hard-down to PagerDuty, with email, Teams, Discord or Telegram alongside — and set a destination to critical-only so the 3am phone stays quiet for things that can wait until Monday. Past the channels, an automation can act on the alert instead of just forwarding it: open the Jira or Linear issue, file the GitHub issue, post to your status page, POST to your own endpoint, or reboot the server and close the incident if it comes back.
- Email, Slack, Teams, Discord, Telegram and PagerDuty
- Per-destination severity, so critical-only channels stay quiet otherwise
- Recovery notices, so “is it back?” is answered without asking
- Or hand it to an automation: Jira, Linear, Notion, GitHub, a webhook, a reboot
Or let an automation act on it
Everything else it handles
The parts that are only interesting when you need them.
Status pages
Turn what you already monitor into a branded public page on your own domain — with the incidents and maintenance windows carried across automatically.
Your own probes
Run a probe on one of your own servers to watch something only reachable from inside your network, alongside the public ones.
Response time history
Per-region response times kept over time, so “it got slower last Tuesday” is a thing you can point at rather than remember.
Server metric alerts
Alert when a server’s CPU, disk or network crosses a threshold — before it becomes a check that fails.
Maintenance windows
Schedule the work, and the alerts, the status page and the uptime figure all understand it was planned.
Automations on monitors
Pause a monitor, mute it for an hour, open a window or reboot a server, triggered by whatever you like.
First monitor live in under a minute
Paste a URL. No agent to install, nothing to configure, and the free plan keeps twenty of them.
Rolling your own vs InfraNest
The difference between knowing something is down and being told the thing that matters.
By hand
- A cron job curling a URL from one machine in one country
- Every dependent service paging you separately for one failure
- Alerts in an inbox nobody reads at 3am
- A cron job that silently stopped, noticed a week later
- Planned work indistinguishable from a real outage
With InfraNest
- Probes on three continents that have to agree before you hear about it
- One incident naming the thing that actually broke
- Warnings to Slack, hard-down to PagerDuty, critical-only where it matters
- A heartbeat monitor that notices the silence within minutes
- Maintenance windows that keep the uptime figure honest
One login, ten modules
Every module is in every plan, Free included — what changes is how much of each you get.
The cost of doing it separately
Buy each piece from a different tool and it adds up fast:
- Domain & DNS
- ~€30
- Uptime monitoring
- ~€29
- SSL tracking
- ~€15
- Status page
- ~€29
- Server panel
- ~€15
- Across 4–5 separate tools
- €100–150/mo
Frequently asked
Where do the checks run from?
From probes in Europe, North America and Asia-Pacific. Every check runs from several at once, and a status only changes when enough of them — across enough regions — agree, which is what stops one flaky location from paging you. You can also run a probe on your own server to watch something that is only reachable from inside your network.
What can it monitor?
Websites and APIs over HTTP, keyword and redirect checks, TCP ports, ping, DNS records, SSL certificates, heartbeat monitors for cron jobs, JSON-asserting API monitors, your servers’ CPU, memory, disk and services, and other providers’ status pages.
How do I stop one outage paging me ten times?
Tell InfraNest which monitors depend on which. When a parent goes down its children are suppressed, so you get one incident naming the root cause instead of an alert per affected check. Flapping is damped separately, so a service bouncing up and down does not page you each time.
Where can alerts go?
Email, Slack, Microsoft Teams, Discord, Telegram and PagerDuty, and each destination can be set to a severity — so a critical-only channel stays quiet for warnings. An automation can take it further and open a Jira, Linear, Notion or GitHub issue, post to your status page, call your own webhook, or act on the server directly.
Does monitoring a cron job need an agent?
No. A heartbeat monitor gives you a URL for your script or cron to call when it finishes. If the call does not arrive within the window you set, you are alerted — which catches the job that silently stopped, the failure a URL check can never see.
What happens during planned maintenance?
Open a maintenance window and the checks inside it stop alerting, the status page says the work was planned, and your uptime figure is not punished for it.
Twenty monitors, on the free plan
Paste a URL and watch it from three continents.
Free plan · No credit card required · Set up in minutes