Incident management, on-call scheduling, monitoring and status pages, in one system that watches your services and wakes the person who can fix them. Run it managed, or run it yourself on Postgres and Node.
Something breaks, the right person finds out, and everyone else can see what is happening without having to ask.
Triggered, acknowledged, resolved, with a timeline of every change — who was told, on what channel, and whether it arrived. Notes, priorities and fields your account defines for itself.
Layers, overrides, and restrictions that mean something: weekdays only, nights, office hours. Written in local time, so a handover stays at nine in the morning when the clocks change.
If the first person does not answer in ten minutes, the next one does. Vacation and out-of-office are known, so a policy never routes to somebody who is away.
Email, SMS, phone call, push, Slack and Teams — acknowledged from the thread, so the first thing somebody does at 3am is not find a browser.
Everything that already emits alerts posts to one address with one key. Deduplicated on a key you choose, so a thousand identical alerts are one incident.
Decide which service an alert belongs to, what its urgency is, and whether it pages at all — before it becomes anybody's problem. Rules are refused when they cannot be understood rather than guessed at.
Forty alerts from one cause are one incident. By content, by time, or by the fields you nominate.
Public or private, on your own domain with a certificate issued automatically. Ninety days of uptime, announcements, postmortems, and subscribers by email, SMS, webhook, Slack or feed.
Announce the work, suppress the paging for it, and have it appear on the status page without writing the same thing twice. Recurring windows in local time.
Which customer-facing services a technical one holds up, so the blast radius of a failure is a question with an answer rather than a conversation.
The list somebody does half of at 3am, done every time: notes, status updates, priority changes, a ticket raised, a webhook posted. Every run recorded step by step, against the version of the workflow that actually ran.
SAML and OpenID Connect, with two-factor for accounts that do not use them. Audit records for everything anybody changed.
Eighteen kinds of check, because "is the website up" is one question out of many and the others are what the outage is usually about.
HTTP status and body, a TCP port, a UDP service that has to answer, DNS records, ping with packet loss — a dropped packet in three is not down and is not well, and no other check can see it.
The outage everybody can see coming and nobody watches for. It fails while there is still time to renew, not on the morning it stops working.
Fetch the sign-in page, post the credentials, fetch the thing only a signed-in caller can see. A health check answering 200 while nobody can sign in is the outage your customers tell you about.
Scripted clicks and assertions in an actual browser, for the failures that only exist once JavaScript has run.
A cron job checks in, and silence is the alert. Tell it the hours it runs in and a weekday job is watched on weekdays — no page on Saturday about work that was never going to happen.
CPU, memory and disk from an agent that needs nothing open to it. Containers, pods, swarm services and Proxmox guests — a host that is up while the eleven containers it exists to run are not is the failure every outside check misses.
A query that has to return what you expect, and switches, firewalls and UPSes asked one question over SNMP — with thresholds on what a counter has gone up by rather than on a number that has been climbing for a year.
Alert on a log line, a metric crossing a threshold, or a span that is failing — the one measurement that says which call inside the request went wrong rather than that the service is slow.
Point an OpenTelemetry collector at it and the same installation that pages you also holds the evidence. One endpoint, one key, one retention setting.
Searchable, correlated, and joined up: the line that mentions a request is on the incident that request caused.
Fingerprinted so the same exception is one thing, filed under the release that introduced it, and marked when one you had resolved comes back.
Not the widest bar in the waterfall — the chain that actually decided the duration, with how much of it each step is answerable for. Work that ran in parallel with something slower cost the request nothing.
A page fetches a list and then one row per item. Invisible in an average, obvious the moment somebody counts them. Counted, and reported as arithmetic rather than as a verdict about your code.
The service graph as your traces describe it, beside the one somebody wrote down — and the difference between them. A dependency nobody declared is the one that takes the site down.
What browsers actually measured on real visits, split by browser, system and device. A page that is fine everywhere except Safari is a shape an average will never show you.
Continuous profiling from the pprof format Go, Java and Node already write, so "why is it slow" has an answer that is not a guess.
Sigma detection rules over the events your tools already forward, with one alert per host or user rather than one for the lot.
Pingz answers the PagerDuty REST API. Every script, dashboard, Terraform module and webhook receiver you already have works against it after one line of configuration changes.
- https://api.pagerduty.com
+ https://pingz.ioThe answers that are hard to retrofit, decided at the start rather than promised for later.
Enforced by the database itself, not by remembering to add a condition to a query. A query that could return another customer's row is a defect here even when the condition is present.
In transit and at rest. Every credential you give it — a webhook URL, a database password, an SNMP community — is sealed before it is stored and opened only by the process that uses it.
Who changed what, when, and from where. Including the operator of the service, whose access to any one account is time-boxed and recorded like everybody else's.
Telemetry is metered separately, so a service that starts logging a million lines a minute cannot stop the thing that pages you.
One command takes an encrypted archive and one restores it — into this installation or any other. An export you cannot restore is not a backup.
The whole product is one container image, four dependencies and a Postgres database. If you ever want to leave, the exit is a documented command rather than a conversation.
Create an account and point something at it. Or take the image and run it yourself — the same build, with no feature held back for a paid tier.
Self-hosting needs Postgres and Node, and nothing else. Compose file and Helm chart included.