Uptime monitoring and status pages for SaaS teamsHear about the outage before your customers post about it
Your product is the app, the API and the jobs that run behind them. InfraNest watches all of it from up to three continents, turns one failure into one incident, keeps your status page up to date without anyone typing, and hands the follow-up to Slack, Jira, GitHub or PagerDuty.
Free plan · No credit card · Set up in minutes
- Made in Germany
- No migration needed
- Tokens encrypted at rest
- Export anytime, no lock-in
- Web appUp · 142 ms
- Public APIUp · 98 ms
- CheckoutSlow in Asia-Pacific
- Nightly billing jobHeartbeat 12 min late
- status.yourapp.comAll systems operational
Every service your customers depend on, in one view.
The problem
The outage your customers announced
On a Thursday afternoon a customer posts a screenshot: checkout fails with an error. Your monitoring is green, because it checks the homepage from one server in Frankfurt, and the homepage is fine. The failing part is the payment API, and it only fails for customers in Asia.
Once someone notices, the alerts arrive all at once. The database is struggling, so the API, the web app and three background jobs all page separately, and the first ten minutes go to working out which alert matters. The status page still says everything is operational, because updating it is someone’s job and that someone is fixing the database.
InfraNest checks every part of your product from up to three continents and tells you when enough of them agree that something is wrong. It turns dependent failures into one incident, updates your status page from the same checks, and hands the follow-up to the tools your team already works in.
The old way
- A cron job pinging the homepage from one server
- Twenty alerts when the database goes down
- A status page someone updates an hour later
- The nightly job that stopped running, noticed a week later
With InfraNest
- On Business, probes on three continents that must agree before you hear about it
- One incident naming the thing that actually broke
- A status page built from the checks, updating itself
- Heartbeat monitors that notice the silence within minutes
How it works
How a SaaS team runs on InfraNest
Checked from where your customers are
On Business, every check runs from probes in Europe, North America and Asia-Pacific at the same time, and a status only changes when enough probes in enough regions agree. You see the outage your customers in Singapore hit even when everything looks fine from Frankfurt, and nobody is woken because one probe had a bad second. Response times are kept per region, so “it got slow in Asia last Tuesday” is something you can point at.
- Probes on three continents on every check, on Business
- A threshold of probes and regions before a status changes
- Response time history per region
- Your own probe inside your network for private services
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.
One failure, one incident
When the database goes down, everything in front of it goes down too. Tell InfraNest which monitors depend on which, and the parent going down silences its children, so you get one incident that names what actually broke. The incident keeps a timeline from detection to resolution, and planned work goes into a maintenance window instead of reading as an outage.
- Dependencies between monitors, so the root cause alerts you once
- An incident timeline: detected, confirmed, updated, resolved
- Maintenance windows that pause alerts and protect the uptime figure
- Heartbeat monitors for jobs that silently stop
Which monitors depend on which is something you declare once, per monitor.
Did we just ship something?
The first question in most incidents, answered before anyone asks it. Link a GitHub repository to the monitors it affects, and an incident that opens within the hour after a deploy names that deploy at the top of its timeline: the commit, the environment, who shipped it, and a link to the run. The same deploys appear as markers on the response-time chart, so a slowdown and the release behind it sit side by side. A deploy only adds information; it never changes a status or the uptime figure.
- The deploy from the hour before, at the top of the incident
- Deploy markers on response-time and server charts
- Link a repository to a monitor, a server or a whole tag
- Works with any deploy job that uses a GitHub environment
A status page nobody has to remember to update
Each service on the page is backed by one of your checks, so when a check fails the page changes on its own. You choose which checks customers see and what they are called. Put it on status.yourapp.com with HTTPS handled for you, let customers subscribe to email updates, and embed a badge or live widget in your app, docs or README. Every incident keeps a permanent link you can paste into a support reply.
- Built from your monitoring, with nothing typed by hand
- Your own domain, logo and colours
- Badges and a live widget for your app, docs and README
- A private team view with on-call and runbook links
Show your live status on your own site, docs or README. The badge updates automatically and links back to this status page.
Layout
Live preview
Major outage
100% uptime over 90 days
Checkout & paymentsMajor outage
Search APIDegraded performance
WebsiteOperational
The strip can hide itself entirely while everything is healthy, so a page that embeds it shows nothing until there is something to say.
<img src="https://status.northwind.example/badge.svg" alt="Status">
<script src="https://status.northwind.example/widget.js" data-layout="summary"></script>
<script src="https://status.northwind.example/widget.js" data-layout="list"></script>
<script src="https://status.northwind.example/widget.js" data-layout="strip"></script>
One cacheable script, rendered into a shadow root, polling a light feed every 60 seconds.
Show “Powered by InfraNest” · Powered by InfraNest
The follow-up, handled in the tools you already use
An alert is only the start. An automation can open the Jira or Linear issue, file a GitHub issue, post an update to your status page, or escalate to PagerDuty if a monitor is still down after fifteen minutes. It works the other way too: a failed GitHub workflow or a PagerDuty escalation can start a rule. Before you switch a rule on, replay it against your own history and dry-run every step.
- GitHub, Jira, Linear and PagerDuty in both directions
- Escalate only if it is still down after a wait
- Replay a rule against your own history before it goes live
- Require approval before anything irreversible
Monitor alert · Status equals down
Do this — actions run in order, stop at the first failure
Then
Otherwise
Add action
Search actions…
Flow
If / branch
Run steps only when conditions match — otherwise the Else steps.
For each
Repeat steps for each item in a list.
Wait
Pause the flow, then continue — e.g. notify, wait, then re-check.
Set a value
Define a named value that later actions in this automation can reuse.
Require approval
Pause for a human to approve before the steps below run.
Put your first monitor live in under a minute
Paste a URL. No agent to install, and the free plan includes twenty monitors.
Getting started
Covered before your next deploy
No agent to install for website and API checks.
Add your endpoints
Paste the URLs of your app, API and docs, and add a heartbeat URL to the jobs that run on a schedule.
Route the alerts
Warnings to a Slack channel, hard-down to PagerDuty, and an automation that opens the ticket.
Publish your status page
Pick the checks customers see, put it on status.yourapp.com and let them subscribe.
How you actually do it
Step-by-step guides for the jobs on this page.
What you get
What changes on day one
customersyou
Who notices an outage first
201
Alerts for one database failure
by handautomatic
How the status page gets updated
The cost of doing it separately
Buy each piece from a different tool and it adds up fast:
- Uptime monitoring
- ~€26
- SSL tracking
- ~€15
- Status page
- ~€26
- Across 3 separate tools
- ~€67/mo
Also in Pro, not counted above: 100 domains with DNS, servers across your cloud providers, 25 automations, Dynamic IP and Drop Catch.
Each line is that tool’s cheapest paid plan. Pro covers all of it: 50 monitors, 100 certificates and 3 status pages on your own domain.
Prices checked October 2026 · dollar prices at the ECB rate
Questions
Questions SaaS teams ask
Where do the checks run from?
From probes in Europe, North America and Asia-Pacific. A status only changes when enough probes in enough regions agree, so one flaky location does not page you. Multi-region checks are included on Business.
Can it monitor more than a URL?
Yes. HTTP and keyword checks, API checks that assert on JSON fields, TCP ports, DNS records, SSL certificates, heartbeat monitors for scheduled jobs, server metrics through the agent, and the status pages of providers you depend on.
How do we avoid an alert storm?
Tell InfraNest which monitors depend on which. When a parent goes down, its children are silenced, so you get one incident naming the root cause. A service that keeps bouncing up and down is damped, so it does not page you every time.
Can the status page run on our own domain?
Yes. Point a CNAME at us and HTTPS is obtained and renewed automatically. If the zone is managed in InfraNest, it can create the record for you.
Does it work with GitHub, Jira and PagerDuty?
In both directions. Events from GitHub, Jira, Linear and PagerDuty can start an automation, and automations can open issues, move tickets, re-run workflows or post to your status page.
Is there an API?
Yes. The API and webhooks are available from Pro, so you can work with InfraNest from your own tooling and deploy scripts.
What does planned maintenance do to our uptime figure?
Nothing. Work inside a maintenance window pauses alerting, shows as planned on the status page and does not count against your uptime.
Which plan does a SaaS team need?
Business: 200 monitors with 30 to 60 second checks from several regions, unlimited status pages and automations, and ten team members. A smaller product can start on Pro: 50 monitors at one-minute checks, three status pages and 25 automations.
Not quite you?
Know about the outage first.
Monitoring from up to three continents, one incident per outage, and a status page that updates itself. Start free with twenty monitors.
Free plan · No credit card required · Set up in minutes