Pingy is a website diagnostic platform. Multiple regional checks confirm whether a failure is real. Then Pingy follows the entire dependency chain to explain why it happened and what needs attention: HTTP behavior, response time, page rendering, DNS delegation and records, SSL certificate chains and protocols, domain registration and locks, reputation, mail authentication, and more.
I built it because an outage alert without context still leaves someone hunting for the problem. Pingy does the investigation as part of the check.
Diagnose the system around the website
Each monitored site gets one operating picture instead of a stack of unrelated tools.
- SSL Certificate Health tracks certificate validity, expiry, hostname matching, the complete chain, transparency logging, HSTS, protocol support, negotiated TLS, cipher strength, key strength, stapling and policy details. The report grades the result and shows exactly which checks passed or need work.
- Domain Health connects registration dates, expiry, registrar information, transfer protection, registry status, authoritative nameservers, response times, DNSSEC, reputation and change history. It turns those signals into a scored health report with visible strengths and gaps.
- DNS Report queries the parent zone and every authoritative nameserver directly. It verifies delegation, agreement between parent and zone, SOA timing, record consistency, mail routing, SPF, DMARC, CAA and security settings. It records the full result instead of reducing DNS to a single lookup.
The same platform also watches HTTP status, keywords, response time, rendered-page health, screenshots and SEO metadata. A user can move from the alert to the probable cause without rebuilding the incident in five other products.
Regional verification is the evidence layer
A fleet of lightweight regional pollers checks sites from the US East and West coasts, Paris, Frankfurt, São Paulo, Sydney and Tokyo. The central control plane runs the application, database, scheduling, analysis and quorum logic. The Laravel 13 and PHP 8.4 application uses PostgreSQL 16 and Redis 7 behind Caddy, while small Dockerized pollers perform the checks from their own network egress.
The pollers use a pull model and carry no state. Each agent leases work, runs it, and posts the result back. They need no inbound connection, can run behind NAT, and scale horizontally by adding another agent. Multiple locations establish whether a symptom is isolated or global. The diagnostic layers then establish why.
Designed to resist false alarms
Every job moves through a Redis-backed queue with lease-as-acknowledgement semantics. If a poller fails to report before its deadline, the system assigns the job to another region and temporarily benches the stalled poller. Backpressure prevents a delayed region from creating duplicate work.
A site is marked down only when independent regions agree. Checks retry transient failures, run a self-health canary, and compare DNS answers across multiple resolvers, including Pingy's own recursive resolvers at the edge. Pingy also recognizes common anti-bot responses and reports a reachable but gated site accurately instead of calling it broken.
Performance and visual proof
Response time is measured as time to first byte, which isolates the origin server's responsiveness from page weight. HTTP checks fetch the document without downloading every asset and run concurrently so one slow target cannot hold up the batch.
A separate Node and Playwright service renders full-page WebP screenshots and extracts SEO metadata. Residential-IP renderers handle sites that block datacenter traffic. Captures are throttled, fail over to another renderer, expire automatically in S3, and pass through image moderation before storage.
A complete operating platform
Alerts share one notification layer for email, SMS, Slack, Discord, Teams, Telegram, Pushover, webhooks and more than 100 services through Apprise. Flap damping suppresses noise from brief blips. Billing is built into the application through Stripe, with per-site plans, and a public API exposes status and live checks programmatically.
When Pingy raises an alert, the user can see whether the problem sits at the origin, in one region, in DNS delegation, in a stale record, in an expiring certificate, in a broken chain, at the registrar, in mail authentication, in reputation data or in the rendered page. The investigation is already underway before anyone opens a terminal.
