Response Time Chart and Uptime Heatmap
The monitor detail page includes two visualizations: a Response Time Chart and an Uptime Heatmap. This article explains how to read them and switch between time periods.
Response Time Chart
The response time chart shows how long checks took over time. Each data point represents one check (or an aggregated average over a period, depending on the time range selected).
Reading the Chart
- Y-axis — response time in milliseconds
- X-axis — time
- Dots/line — each point represents the response time for a check (or averaged group of checks)
- Red markers — failed checks (timeout, wrong status code, connection error)
- Gaps — no data for that period (monitor was paused, or checks haven't run yet)
What to Look For
- Flat, low line — consistent, healthy response times
- Spike — single check with a much higher response time than normal; usually a transient event
- Sustained elevation — response times trending higher over time; may indicate growing server load
- Cliff drop — sudden improvement (e.g., after a fix or deployment)
Uptime Heatmap
The uptime heatmap shows check results as a grid of color-coded cells, making it easy to spot patterns of downtime at a glance.
Reading the Heatmap
- Green cells — successful checks during that time block
- Red cells — failed checks (one or more failures in that time block)
- Gray cells — no data (monitor was paused or not yet monitoring)
Each cell represents a time block — the size depends on the time range selected (e.g., hourly blocks for a 24-hour view, daily blocks for a 30-day view).
What to Look For
- Isolated red cells — brief, isolated incidents; likely one-off failures
- Contiguous red cells — sustained outage covering that time range
- Regular pattern of red — scheduled downtime, recurring issue, or a maintenance job that takes the endpoint offline periodically
Switching Time Periods
Both the chart and heatmap share the same time period selector. Click 24h, 7d, or 30d to change the view. The charts update immediately.
- 24h — hourly resolution; best for diagnosing recent issues
- 7d — daily aggregation; useful for week-over-week comparison
- 30d — monthly view; useful for SLA reporting
Related Articles
Still have questions? Contact support.
Related Articles
Understanding Uptime Percentage
Uptime percentage is the most commonly used metric for describing service reliability. This article explains how PulseAPI calculates it and how to interpret the numbers. How Uptime Percentage Is Calculated Uptime percentage = (successful checks ÷ ...
Understanding Response Times
Every check PulseAPI performs records how long the HTTP request took. This article explains what response time means, what affects it, and how to interpret the data. What PulseAPI Measures Response time is measured from the moment PulseAPI initiates ...
Response Time Spikes Explained
A response time spike is a check result where the response time was significantly higher than normal — then returned to normal on the next check. This article explains what causes spikes and how to interpret them. What a Spike Looks Like On the ...
Alert Rule Conditions: Response Time
A response time alert rule fires when a check takes longer than a threshold you define. This article explains how to configure response time rules and recommends sensible starting thresholds. How It Works After every check, PulseAPI records the ...
Alert Rule Conditions: Uptime Percentage
An uptime percentage alert rule fires when your monitor's uptime over a specified time window drops below a threshold. This is ideal for SLA-based alerting and reducing false positives from one-off check failures. How It Works Instead of evaluating ...