Who this is for, and what breaks for them.
The same monitoring engine underneath. What changes between these is how many regions vote, who gets woken up, and what you have to show for it afterwards.
Bloggers and indie hackers
One site, nobody watching it, no budget for a monitoring tool.
You shipped it and moved on, which is the correct thing to have done. The problem is that you are now the only person checking whether it works, and your browser has it cached, its DNS already resolved, and possibly a service worker handing you a version no new visitor will ever get.
- The free tier is the whole product for one site, not a trial of it
- Certificate expiry warnings before the certificate expires, not after
- A public status page, so you have somewhere to point people
- Checked from outside your network, so a warm cache and an already-resolved DNS record cannot hide an outage from you
There is no trial clock on the free tier and no card to remove. If the site stays one site, this stays the whole product; if it grows, upgrading is a plan change rather than a migration.
- Free plan
- 1 region
- no quorum
One address to watch
You gave Pingara one URL. That is the whole configuration — an address, a schedule, and the range of status codes you are willing to call healthy.
The check runs
Your region requests the endpoint on schedule and records where the time went — DNS, connection, TLS handshake, response.
A region decides for itself · can stop here
One failed request changes nothing. A region has to fail 2 checks in a row before it votes that your service is down.
No vote to take
A single-region monitor has nobody to agree with, so its own verdict stands. This is the step that multiple regions buy you.
Maintenance is checked · can stop here
A maintenance window reaches a monitor through the status pages it is on, so this only applies to a monitor attached to one. When it does apply, you choose separately whether to skip opening an incident and whether to stay silent — and the monitor still shows as down either way.
The incident opens
One incident per monitor, not one per failed check. Further failures keep updating the same incident rather than opening another.
You are told
Pingara sends to email, then emails any member of your organisation that channel did not already cover. A failed send is retried with backoff before it is written off.
It comes back
Recovery is confirmed the same way the outage was: 2 clean checks in a row. A recovery notice goes out, and when the model can make something of the timings, an AI-written summary of possible causes is attached to the incident for you to read.
Somewhere to point people
Your status page reads the same monitor state this flow just changed, so it is already right by the time anyone loads it. You do not have to post an update while you are still working out what happened.
One region, so there is nobody to take a vote with — the region's own two consecutive failures are the whole confirmation.
Startups
More services than people, and a customer who will churn quietly.
You have a marketing site, an API, a checkout flow and a queue worker, and one person who happens to notice when things break. The outages that cost you most are the ones nobody reports — a signup form that fails does not file a support ticket, it loses the person who was about to become a customer.
- A keyword check on the response body, so a page that returns 200 with an error rendered inside it still fails
- One monitor per service, so the alert names the thing that broke rather than the domain
- Uptime and SLA attainment per service against a target you set
- Escalation on Pro, so an alert nobody acknowledges reaches someone else
Uptime is a number you will eventually have to quote to somebody — an investor, a customer, a contract. Setting a target per monitor now means the answer is computed by the time the question arrives, rather than pieced together the week it is asked for.
- Pro plan
- 4 regions
- quorum of 2
One monitor per service
The marketing site, the API and the checkout page are separate monitors on separate schedules, so a failure is attributed before anyone reads it. Checkout also carries a keyword check: the response body has to contain a string you chose, or the check fails even though the status code did not.
The check runs
Every configured region requests your endpoint on its own schedule and records where the time went — DNS, connection, TLS handshake, response.
A region decides for itself · can stop here
One failed request changes nothing. A region has to fail 2 checks in a row before it votes that your service is down.
The regions have to agree · can stop here
2 of your 4 regions must independently reach that conclusion, and only regions currently reporting get a vote. One region having a bad network path cannot move the monitor on its own.
Maintenance is checked · can stop here
A maintenance window reaches a monitor through the status pages it is on, so this only applies to a monitor attached to one. When it does apply, you choose separately whether to skip opening an incident and whether to stay silent — and the monitor still shows as down either way.
The incident opens
One incident per monitor, not one per failed check. Further failures keep updating the same incident rather than opening another.
You are told
Pingara sends to Slack and email, then emails any member of your organisation those channels did not already cover. A failed send is retried with backoff before it is written off.
Nobody acknowledges
Escalation is a Pro feature and it is off until you set a delay. Once you have, an incident left unacknowledged escalates on that schedule, repeats if you asked it to, and stops at a cap. Acknowledging it stops the escalation.
It comes back
Recovery is confirmed the same way the outage was: 2 clean checks per region, agreed by 2 of them. A recovery notice goes out, and when the model can make something of the timings, an AI-written summary of possible causes is attached to the incident for you to read.
You know which service it was
Because each service is its own monitor, the alert names it, the incident belongs to it, and its own history is the one that moved. There is no step where somebody works out which of four things went wrong.
Four regions, so two have to independently agree before anyone is told. Once someone acknowledges, the escalation chain stops.
MSPs and agencies
Other people's infrastructure, and a phone that rings when it breaks.
You are answerable for estates you did not build and cannot always change. What you need is to know before the client does, and to be able to show what happened afterwards without reconstructing it from memory.
- Switch between client organisations without signing out
- Or keep one organisation and group monitors by client on a status page
- A per-client status page, public or behind a login, so they can check without calling
- Maintenance windows on Pro, so planned work on a client's estate is expected rather than paged
Each organisation carries its own plan and its own subscription. Separate organisations keep clients cleanly apart; one organisation with grouped monitors is cheaper. Which of those is right depends on how many clients you have and whether they ever need their own login.
- Pro plan
- 4 regions
- quorum of 2
Monitors grouped by client
Each client's services are their own monitors, and a status page can put them in named sections so one page reads as several. A monitor belongs to whichever pages you put it on — which is also the only way a maintenance window ever reaches it.
The check runs
Every configured region requests your endpoint on its own schedule and records where the time went — DNS, connection, TLS handshake, response.
A region decides for itself · can stop here
One failed request changes nothing. A region has to fail 2 checks in a row before it votes that your service is down.
The regions have to agree · can stop here
2 of your 4 regions must independently reach that conclusion, and only regions currently reporting get a vote. One region having a bad network path cannot move the monitor on its own.
Maintenance is checked · can stop here
A maintenance window reaches a monitor through the status pages it is on, so this only applies to a monitor attached to one. When it does apply, you choose separately whether to skip opening an incident and whether to stay silent — and the monitor still shows as down either way.
The incident opens
One incident per monitor, not one per failed check. Further failures keep updating the same incident rather than opening another.
You are told
Pingara sends to a webhook and Slack, then emails any member of your organisation those channels did not already cover. A failed send is retried with backoff before it is written off.
Nobody acknowledges
Escalation is a Pro feature and it is off until you set a delay. Once you have, an incident left unacknowledged escalates on that schedule, repeats if you asked it to, and stops at a cap. Acknowledging it stops the escalation.
It comes back
Recovery is confirmed the same way the outage was: 2 clean checks per region, agreed by 2 of them. A recovery notice goes out, and when the model can make something of the timings, an AI-written summary of possible causes is attached to the incident for you to read.
The ticket and the client's page are already done
The webhook payload is structured — event, monitor, incident, affected regions — so your ticketing system has what it needs without anyone retyping it. The client's status page moved at the same moment, which is usually the call you did not have to take.
A monitor can sit on more than one status page and carry a different display name on each, so the client's page can say what the client calls it while yours says the hostname.
DevOps and SRE teams
You already know what an outage costs. You want the shape of the degradation before it becomes one.
Availability is the easy number. The one that predicts your next incident is the tail: a p99 drifting upward for a fortnight while the median stays perfectly flat, because one dependency is slow for one in a hundred requests.
- p50, p95 and p99 per rollup period, kept after the raw checks are purged
- Apdex against a threshold you choose, so the score means what you need it to
- Mean time to acknowledge and resolve, measured from detection rather than from when someone noticed
- A read-only REST API for monitors, checks, incidents and public status
None of this is trapped in the dashboard. The REST API reads monitors, checks and incidents; the rollups behind the percentile charts come out as CSV. Whatever you already use for analysis can have the same numbers.
- Pro plan
- 4 regions
- quorum of 2
An endpoint with a latency rule
As well as a status code, the monitor carries a slow-response threshold in milliseconds and the number of consecutive slow checks that has to hold. Cross both and the monitor is degraded rather than down — a different state, reached through the same agreement below.
The check runs
Every configured region requests your endpoint on its own schedule and records where the time went — DNS, connection, TLS handshake, response.
A region decides for itself · can stop here
One failed request changes nothing. A region has to fail 2 checks in a row before it votes that your service is down.
The regions have to agree · can stop here
2 of your 4 regions must independently reach that conclusion, and only regions currently reporting get a vote. One region having a bad network path cannot move the monitor on its own.
Maintenance is checked · can stop here
A maintenance window reaches a monitor through the status pages it is on, so this only applies to a monitor attached to one. When it does apply, you choose separately whether to skip opening an incident and whether to stay silent — and the monitor still shows as down either way.
The incident opens
One incident per monitor, not one per failed check. Further failures keep updating the same incident rather than opening another.
You are told
Pingara sends to PagerDuty and Slack, then emails any member of your organisation those channels did not already cover. A failed send is retried with backoff before it is written off.
Nobody acknowledges
Escalation is a Pro feature and it is off until you set a delay. Once you have, an incident left unacknowledged escalates on that schedule, repeats if you asked it to, and stops at a cap. Acknowledging it stops the escalation.
It comes back
Recovery is confirmed the same way the outage was: 2 clean checks per region, agreed by 2 of them. A recovery notice goes out, and when the model can make something of the timings, an AI-written summary of possible causes is attached to the incident for you to read.
The rollups outlive the checks
Raw check results are deleted on your plan's retention schedule. The hourly and daily rollups they were folded into first are not on that schedule, so the p50, p95 and p99 for every period stay behind — and the CSV export reads those, not the raw rows.
PagerDuty receives a dedup key, so the trigger and its resolve correlate into one incident on your side rather than two unrelated pages.
Enterprises
Somebody will ask you to evidence this, and “it felt fine” is not an answer.
The monitoring is the easy part. What takes the time is proving, a quarter later, what your availability actually was, who was told, who acknowledged it, and how long it took — without three people reconstructing it from a chat history.
- Four roles, from full ownership down to genuinely read-only
- SLA attainment per monitor against a target you set, with CSV export on Pro
- An append-only record of every acknowledgement, status change and escalation notice
- Status pages you can keep private, behind your team's login rather than on the open internet
Two things worth knowing before you get far into a procurement process. Sign-in is email and password with two-factor authentication. And Pingara is a monitoring product, not a compliance programme — if your process requires a formal third-party audit report, we do not have one to hand you.
- Pro plan
- 4 regions
- quorum of 2
The services carrying a target
Each monitor can hold an availability target you set, and it is that number the daily rollups get measured against later. Monitors without one still run; they simply have nothing to be judged against.
The check runs
Every configured region requests your endpoint on its own schedule and records where the time went — DNS, connection, TLS handshake, response.
A region decides for itself · can stop here
One failed request changes nothing. A region has to fail 2 checks in a row before it votes that your service is down.
The regions have to agree · can stop here
2 of your 4 regions must independently reach that conclusion, and only regions currently reporting get a vote. One region having a bad network path cannot move the monitor on its own.
Maintenance is checked · can stop here
A maintenance window reaches a monitor through the status pages it is on, so this only applies to a monitor attached to one. When it does apply, you choose separately whether to skip opening an incident and whether to stay silent — and the monitor still shows as down either way.
The incident opens
One incident per monitor, not one per failed check. Further failures keep updating the same incident rather than opening another.
You are told
Pingara sends to Microsoft Teams, PagerDuty and a webhook, then emails any member of your organisation those channels did not already cover. A failed send is retried with backoff before it is written off.
Nobody acknowledges
Escalation is a Pro feature and it is off until you set a delay. Once you have, an incident left unacknowledged escalates on that schedule, repeats if you asked it to, and stops at a cap. Acknowledging it stops the escalation.
It comes back
Recovery is confirmed the same way the outage was: 2 clean checks per region, agreed by 2 of them. A recovery notice goes out, and when the model can make something of the timings, an AI-written summary of possible causes is attached to the incident for you to read.
The record wrote itself
Every acknowledgement, status change and escalation notice was appended to the incident's timeline as it happened — the notice numbered against its cap, the person who acknowledged named from a verified membership. Nothing in it is edited afterwards, and the attainment export is a separate read of the daily rollups against the target you set.
A delivery that fails is recorded as failed, with a readable reason, instead of disappearing. The timeline shows the notices that did not land alongside the ones that did.
Start with one monitor.
Every segment above starts the same way: one URL, no card. Move to Pro when the story on this page becomes yours.