Response Time Monitoring
Speed is the key to success. Monitor your applications' latency in milliseconds and catch slowdowns before they impact user experience.
Performance measurement beyond uptime
Just because a website is "online" does not mean it is working correctly. A slow server can frustrate a user as thoroughly as a total outage. Pulsitor times the complete request on every check — DNS lookup, connection, TLS handshake and transfer together in one figure — and keeps every measurement, so latency becomes a trend you can read instead of a feeling. You set the millisecond threshold at which slow stops being acceptable; crossing it opens an incident like any other failure.
How the measurement works
What makes Pulsitor powerful out of the box.
Measured on every single check
Every check times the complete request, from the DNS lookup to the last byte, and stores the result in milliseconds. One figure per run, measured the same way each time.
Your own definition of too slow
Define your own limits for "normal" response. If latency exceeds the set threshold, we inform you immediately.
A trend, not one number
The monitor detail plots every measurement from the last 24 hours or the last 7 days, next to the average and the uptime for the same window.
Faster apps, happier users
Consistent speed for users
Improve user experience by eliminating random slowdowns and ensuring consistent speed.
Independent evidence for an SLA
Monitor compliance with service level agreement (SLA) response parameters for your clients with independent evidence.
A starting point for developers
Get valuable clues for your developers that help quickly uncover the cause of performance degradation.
Response time monitoring at a glance
What is measured, and what turns it into an incident.
| Property | Value |
|---|---|
| What is measured | Total response time of the check, in milliseconds |
| Alert threshold | Set per monitor, in milliseconds |
| Timeout | 1 to 60 seconds |
| In the app | Average, uptime and every measurement over 24 hours or 7 days |
| Check interval | 15 to 180 seconds, depending on plan |
| Notification channels | 14 |
| Available on | Paid plans, from 6 EUR per month |
Response time questions
What the number means and when it alerts.
What exactly is measured?
The total time the check needed to get its response, in milliseconds, recorded on every run — so the chart shows the trend rather than a single reading.
How do I set the threshold?
In milliseconds, per monitor. When a check comes back slower than that value an incident opens and your channels are notified, the same path a full outage takes.
Does a slow response count as downtime?
It opens its own incident type, separate from an unreachable host, so "the site is gone" and "the site is crawling" never arrive as the same alert.
What history do I get?
Every measurement is stored. The monitor detail plots them over the last 24 hours or the last 7 days, together with the average and the uptime for that window, so a slow creep upwards is visible before it becomes an incident.
Which plans include response time monitoring?
Every paid plan, starting at 6 EUR per month.
How to start measuring response time
Enter the target URL of your API endpoint or important landing page.
Set the maximum acceptable response time at which an alarm should be triggered.
Connect the monitor to your communication tools and track results in real-time.