Understanding Uptime Statistics & Reports
WebhookBeam collects a health check result every time it pings your monitored link. Over time, these results build up into a rich set of statistics you can use to understand the reliability and performance of your services.
Uptime Percentages (24h / 7d / 30d)
The uptime percentage tells you what fraction of health checks returned a successful response within a given time window. It is calculated as:
Uptime % = (Successful Checks ÷ Total Checks) × 100
WebhookBeam shows three uptime windows for every monitored link:
| Window | What It Shows | Typical Use |
|---|---|---|
| 24h | Availability over the last 24 hours. | Day-to-day operational health. Sensitive to recent incidents. |
| 7d | Availability over the last 7 days. | Weekly reliability. Smooths out short-lived blips. |
| 30d | Availability over the last 30 days. | Monthly SLA reporting. Used on public status pages. |
How to Read Uptime Percentages
- 100% - Every single check succeeded. No downtime detected.
- 99.9% - "Three nines". About 43 minutes of downtime per month.
- 99.5% - About 3.6 hours of downtime per month.
- 99% - "Two nines". About 7.3 hours of downtime per month.
- Less than 99% - Significant reliability issues worth investigating.
Note: Uptime percentages are rounded to 2 decimal places. If there are no health checks recorded in a window (e.g. a newly added link), the percentage shows as N/A.
Response Time Metrics
Response time measures how long your endpoint takes to return a response, recorded in milliseconds (ms) for every health check. Only successful checks (where the site was considered "up") are included in response time statistics - failed checks are excluded.
| Metric | Description | What It Tells You |
|---|---|---|
| Current (ms) | Response time from the most recent health check. | Immediate snapshot of performance right now. |
| Average 24h (ms) | Mean response time over the last 24 hours. | Typical day-to-day performance baseline. |
| Average 7d (ms) | Mean response time over the last 7 days. | Weekly performance trend. |
| P95 (ms) | 95th percentile response time - 95% of all checks completed within this time. | Worst-case performance, excluding extreme outliers. More realistic than the max. |
What Is P95?
The P95 (95th percentile) is the response time value below which 95% of your health checks fall. For example, if your P95 is 450 ms, it means 95 out of 100 checks completed in under 450 ms - and only 5% were slower.
P95 is a better measure of "slow performance" than the maximum, because the maximum can be skewed by rare network anomalies. If your P95 is significantly higher than your average, your service may have intermittent slowdowns worth investigating.
Response Time Benchmarks
- Under 100 ms - Excellent. Fast server, close to the monitoring server.
- 100–300 ms - Good. Typical for well-optimized APIs.
- 300–600 ms - Acceptable. May indicate geographic distance or mild load.
- 600–1000 ms - Slow. Consider investigating server performance.
- Over 1000 ms - Very slow. Users will notice. Investigate immediately.
Health Check Counts
The stats panel also shows a breakdown of how many checks were performed and how many succeeded or failed:
| Metric | Description |
|---|---|
| Total Checks (24h) | Total number of health checks performed in the last 24 hours. For a 5-minute interval, this is approximately 288 checks per day. |
| Successful Checks | Checks where the endpoint responded with an expected HTTP status code within the timeout. |
| Failed Checks | Checks where the endpoint was unreachable, timed out, or returned an unexpected status code. |
Expected Check Frequency
The number of checks per day depends on your configured check interval:
| Check Interval | Checks per Hour | Checks per Day |
|---|---|---|
| 1 minute | 60 | 1,440 |
| 5 minutes | 12 | 288 |
| 10 minutes | 6 | 144 |
| 30 minutes | 2 | 48 |
| 1 hour | 1 | 24 |
Incident History & Timeline
The stats panel shows how many incidents occurred in each time window:
| Window | Description |
|---|---|
| Incidents (24h) | Number of downtime incidents that started in the last 24 hours. |
| Incidents (7d) | Number of downtime incidents that started in the last 7 days. |
| Incidents (30d) | Number of downtime incidents that started in the last 30 days. |
Incident Timeline
Each incident has a detailed timeline you can view on the Incidents page or the public status page:
- Started at - When the first failing health check triggered the incident.
- Ended at - When a successful health check resolved the incident (or the time you manually resolved it).
- Duration - Displayed in human-readable format: seconds, minutes, hours, or days.
- Cause - The type of failure: Timeout, Connection Error, SSL Error, DNS Error, HTTP Error, or Unknown.
- Timeline updates - Chronological posts from you or auto-generated by the health checker, showing the progression from Investigating → Identified → Monitoring → Resolved.
Health Check History & Data Retention
WebhookBeam stores health check records for a limited period depending on your subscription plan. Older records are automatically deleted by a daily cleanup task.
| Plan | History Retention | Max Check Records (5-min interval) |
|---|---|---|
| Free | 7 days | ~2,016 records per link |
| Starter | 30 days | ~8,640 records per link |
| Pro | 90 days | ~25,920 records per link |
What This Means for Statistics
- Free plan - The 7-day and 30-day uptime percentages for Free users are calculated from data within the 7-day retention window. Once records expire, historical stats for those windows are no longer available.
- Starter plan - Up to 30 days of full history. The 30-day uptime percentage is accurate for the full window.
- Pro plan - Up to 90 days of history. Well-suited for monthly SLA reporting and trend analysis.
Incident records are kept independently of health check records and are not subject to the same retention limits - your incident history remains accessible even after health check records expire.