Features
Endpoint checks, alerts,
Apdex and reporting
Six capabilities for developers and ops teams. Most work on defaults from your first check.
Monitoring
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, covering DNS, connection, TLS handshake, and the response itself.
How to set up an HTTP monitor| Name | Status | Response Time |
|---|---|---|
| Storefront APIHTTP | up | 128 ms |
| Checkout ServiceHTTP | down | 5000 ms |
| Session StoreTCP | degraded | 8 ms |
| Storefront WebHTTP | up | 620 ms |
| Asset CDNHTTP | up | 22 ms |
| Edge Gateway (Singapore)Ping | unknown | 61 ms |
| Staging APIHTTP | degraded | 210 ms |
| Dev SandboxPing | paused | - |
| Recommendations APIHTTP | pending | - |
| Mail routing (MX)DNS | up | 31 ms |
| Realtime price feedWebSocket | up | 74 ms |
- 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
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.
Setting up alertsIncident started
Oct 17, 2026 08:31:17
Alert sent via email to 4 recipients
Oct 17, 2026 08:31:17
Alert sent via PagerDuty
Oct 17, 2026 08:31:22
Alert delivery via slack failed: webhook returned 404
Oct 17, 2026 08:31:25
Acknowledged byPRPriya Raman
Oct 17, 2026 08:35:29
Status changed to IdentifiedbyPRPriya Raman
Oct 17, 2026 08:35:47
RCA report generatedbyPRPriya Raman
Oct 17, 2026 08:37:57
- 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.
Reporting
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.
Latency Overview
p50, p95, and p99 response times (ms)
- 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
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.
How Apdex is scored- 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.
Regions
Multi-region checks with quorum on Pro
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.
Intervals and regions- Two consecutive failures before a region votes, and two successes before it votes recovered
- A single region decides on its own; from two up, at least half must agree, rounded up, 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
Checks run from any of four regions:
- US East (N. Virginia)
- US West (Oregon)
- Europe (Ireland)
- Asia Pacific (Singapore)
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.
Root cause
AI root cause hints
Pingara already measures where the time went on every check, across DNS, TCP connect, TLS handshake and 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.
How the hints are made- 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.
Get started
Point it at one URL.
The free tier is one monitor, no card, and no time limit. Everything above is there when you need it.