Distributed consensus monitoring
Monitoring that shows its evidence
Pinggy runs checks from the nodes you operate, agrees on what they observed, and keeps the record behind every state it publishes. It is server-rendered HTML with no JavaScript, and PostgreSQL is the only thing it stores durable state in.
What it checks
- HTTP
- ICMP
- TCP
- TLS
HTTP(S) checks can assert on the response content returned, not only that something answered; TLS checks track certificate expiry so a certificate does not lapse unnoticed.
What "evidence" looks like
Every monitor's state is read off the same list an operator sees first: what needs attention, ranked in one documented priority order, never a wall of green.
Example data — not a reading of this installation
- Incident openexample-checkout-api
A confirmed incident is open for this monitor.
- DOWN, unconfirmedexample-edge-lb-3
Consensus is DOWN; confirmation is at 2 of 3 evaluations.
- Below quorumexample-us-east-db
Cannot reach quorum: 2 of the 3 required replicas are assigned, so no evaluation can be conclusive.
- Unknownexample-partner-webhook
No recent consensus: this monitor has not been evaluated recently enough to assert a state.
What it does
Consensus and assurance
Run each monitor at 3, 5, or 7 replicas with a matching quorum of 2, 3, or 4, backed by what the assigned nodes' evidence supports together. A monitor publishes UP, DOWN, DEGRADED, UNKNOWN, or PAUSED — never whichever probe answered last.
Incidents and reliability
A confirmed incident requires a configurable N of M run of evidence-advancing evaluations, not one bad check. Once confirmed, it delivers to the notification channels you configured — ntfy, or a generic signed webhook.
Maintenance and status pages
Announce a maintenance window, including a recurring one, and it becomes part of the record rather than a reason to be paged. A published status page shows strict uptime and the maintenance-adjusted figure side by side — never one standing in for the other.
Automation and the API
A scoped, versioned HTTP API and its published OpenAPI document cover the same operations the screens do, with import and export for moving configuration in and out.
Deployment and fleet planning
You enrol the nodes. Pinggy places each monitor on the nodes that can carry it and keeps that placement current as the fleet changes, so a check keeps running where you need it observed.
How Pinggy talks about coverage
- Losing assigned replicas may leave a monitor under-replicated: it is being watched by fewer nodes than it asks for.
- A monitor may remain quorum-capable while under-replicated — the evidence it still collects can be enough to agree on a state.
- When Pinggy cannot obtain sufficient fresh evidence to reach consensus, the monitor's state is UNKNOWN rather than the last thing it said.
- Inability to reach quorum and under-replication are related but distinct coverage conditions, and Pinggy reports them separately.
This page is the public front door to a Pinggy installation. It carries nobody's data and reads nothing about the deployment it is served from.
Where to go next
Read the documentation, or sign in to an installation you already operate.