Everything Pingara does, and what each part is for.

Endpoint monitoring

Watch an HTTP or HTTPS endpoint, a TCP or UDP port, a host over ICMP, a DNS record, or a WebSocket. Pingara checks it on your schedule from outside your network, and records the full timing breakdown of every check — DNS, connection, TLS handshake, and the response itself.

• Six check types: HTTP(S), keyword, TCP/UDP, ping, DNS records, and WebSocket
• Match on status code, or on text that must appear in the body
• Or invert it: fail when text appears, so a page serving an error inside a 200 still fails
• Custom request headers and body, on every plan
• Certificate expiry warnings 30, 14 and 7 days ahead, on every plan
• Checks as often as every 30 seconds on Pro, every 5 minutes on Free

Alerting

When a monitor goes down, recovers, slows down, or is paused, Pingara tells you wherever you actually look. Choose which channels hear about which of those, per monitor.

• Six channels: email, Slack, Discord, Microsoft Teams, PagerDuty, and webhooks
• A failed send is retried with backoff before it is written off
• Escalation chains on Pro: escalate after N minutes unacknowledged, repeat, and cap
• Fire a test incident and watch it arrive before you need it to

Configure nothing at all and you still get an email — the fallback is on by default, and you have to switch it off yourself before a monitor can fail quietly.

Dashboards and reporting

Uptime, latency and incident history for every monitor, and for the organisation as a whole. Response time is recorded on every check and rolled up hourly and daily, so your history keeps going after the raw checks behind it have aged out.

• p50, p95 and p99 latency per rollup period
• Uptime and SLA attainment per monitor, with CSV export on Pro
• Incident timeline with who acknowledged, who resolved, and when
• Mean time to acknowledge and resolve, both measured from detection
• Raw checks kept 7 days on Free and 365 on Pro, with the rollups kept past that

Averages always render with the count behind them. If you acknowledged one incident out of fifty, you see both numbers, not just the flattering one.

Apdex scoring

Apdex turns raw response times into one number between 0 and 1, by scoring every check against a threshold you set per monitor: fast enough, tolerable, or too slow. It is how you notice a service getting worse over a month rather than over a minute.

• Set the satisfying-response threshold per monitor
• Scored into the same hourly and daily rollups as latency
• Recorded with the threshold it was scored against, so old scores stay readable

Apdex tells you the story afterwards. It is deliberately not what pages you — that is a latency rule, confirmed the same way a down and a recovery are.

Multi-region checks with quorum

A single failed request from a single place is not an outage — it is one bad request. So a region has to fail twice in a row before it votes at all, and on Pro, where a monitor runs in more than one region, enough regions have to independently agree before anything reaches you.

• Two consecutive failures before a region votes, and two successes before it votes recovered
• A majority of regions must agree, with a floor of two
• A region that stops reporting stops voting, rather than voting stale
• All 4 regions on Pro, 1 region on Free

And when every region assigned to a monitor goes dark at once, Pingara does not guess. It marks the monitor unknown and says plainly that this is our infrastructure having a problem, not your site.

AI root cause hints

Pingara already measures where the time went on every check — DNS, TCP connect, TLS handshake, the response itself. When something breaks, it hands that breakdown to a model and asks what could explain it, so you start investigating from somewhere rather than from nothing.

• Ask for hints on any single check, from its own timing breakdown
• A written summary, a timeline and probable causes, generated when an incident resolves
• Evidence quoted alongside each suggestion, so you can check its reasoning

These are suggestions, not findings. They are there to give you somewhere to start looking, and they are wrong often enough that you should treat them that way.