Response Time Monitoring
Response time monitoring is the continuous measurement of how long a website or API takes to respond on every check. MonitorUrs records the response time in milliseconds each time a probe runs, alongside the HTTP status code and response size, so you can track performance trends and spot slowdowns before they turn into outages.
Last updated: June 2026
Why response time matters
A site that is technically "up" can still be failing your users. When pages take five, ten or fifteen seconds to load, visitors abandon carts, searches feel broken and API clients start timing out. Slow responses are one of the clearest early-warning signs that something is going wrong: a database is under load, a dependency is degrading, memory is leaking or traffic has outgrown the server. Long before a service returns an error, it usually gets slow.
That is why response time deserves to be measured, not assumed. A simple up/down check tells you nothing about the experience your users are actually having. By recording how long every check takes, MonitorUrs gives you a continuous record of performance so a gradual slowdown becomes visible as a trend instead of arriving as a sudden outage. Watching latency lets you act while you still have time to react.
How MonitorUrs measures response time
You add the site or endpoint you want to watch as a probe — the URL MonitorUrs should request. Every time that probe runs, MonitorUrs sends an HTTP/HTTPS request and times the round trip. The result is stored as ResponseMs, the response time in milliseconds, captured on the same check that validates the status code and the response body.
There is no separate test to schedule and no extra tooling to wire up: response time is recorded automatically on every probe check. Checks run on a configurable interval — every 15 minutes by default — so each run adds a fresh measurement to the record. Because the timing is captured alongside the status code and response size, every check gives you a small, complete snapshot of both availability and performance at that moment in time.
What you can see and track
Each probe check records a small set of values that together describe the health of the request. Response time is the headline metric, but it is most useful read together with the status code and response size:
| Metric recorded per check | What it tells you |
|---|---|
Response time (ResponseMs) | How long the request took, in milliseconds, on this specific check — the core performance signal. |
| HTTP status code | Whether the server returned the expected code (such as 200), recorded on the same check as the timing. |
| Response body length | The character length of the response body, useful for spotting truncated, empty or unexpectedly large pages. |
| Check timestamp | When the measurement was taken, so values line up into a trend over time. |
Reading these together turns raw numbers into context. The table below shows how the same response-time figure can mean very different things depending on what you are monitoring — interpretations are illustrative, since acceptable latency always depends on your own service:
| Example response time | How you might read it |
|---|---|
| Under 200 ms | Snappy. Typical of a healthy, well-cached API or a static page on a responsive server. |
| 200–800 ms | Comfortable for most pages and endpoints. Worth tracking the trend, not worrying about a single check. |
| 800 ms–3 s | Noticeably slow for users. A rising trend here is an early sign of load or a degrading dependency. |
| Over 3 s (or near timeout) | A likely problem in progress. Sustained values this high often precede failures and outages. |
Catching slowdowns before outages
Most outages do not happen instantly. A service degrades first — response times creep up over hours or days as load grows, a query gets slower, or a downstream dependency starts struggling. Because MonitorUrs records ResponseMs on every check, that slow drift is captured as a visible trend rather than disappearing into a single pass/fail result. When you review the history and see latency climbing, you have the chance to investigate and fix the underlying cause before it tips over into a hard failure.
It is worth being precise about how alerting works. For website and API probes, alerts via Telegram, SMS and Email fire on probe failures — after a configurable number of consecutive failed checks — not on a numeric latency value. A request that is slow but still succeeds within the timeout is recorded as a measurement, not flagged as a failure. Response time on probes is therefore something you measure and track for trend analysis, and you review it on the dashboard and in the history. If a request slows down enough to exceed the probe's request timeout, that counts as a failed check and can contribute to a failure alert. For server-side metrics such as CPU, memory or disk, MonitorUrs additionally supports numeric metric alert rules with thresholds and hysteresis, which is a separate mechanism from probe checks.
Response time in your incident history
Every per-check measurement is logged, which means your incident history doubles as a performance record. Instead of guessing whether the site "felt slow last week," you can look back at the actual recorded response times and see exactly when a slowdown began, how steep it was and whether it lined up with a deploy, a traffic spike or an incident. That history is useful both for diagnosing the root cause after the fact and for proving the level of performance you have delivered over time.
For the live picture, current response-time values appear on the real-time status dashboard, so you can see at a glance how each probe is performing right now. Together, the dashboard answers "how is it doing this moment?" and the history answers "how has it been trending?"
Use cases
- E-commerce performance — track how quickly product and checkout pages respond, since slow pages cost conversions even when nothing is technically broken.
- API latency tracking — record how long your endpoints take to answer on every check, so you can show clients and teammates real numbers rather than impressions.
- Post-deploy checks — compare response times before and after a release to confirm a change did not quietly make things slower.
- Capacity planning — watch latency drift upward as traffic grows so you can scale before users feel the strain.
- Agency reporting — keep a per-client record of performance trends alongside uptime for transparent monthly reviews.
How it fits with uptime and website monitoring
Response time monitoring is the performance dimension of the same probe checks that power availability monitoring. Uptime monitoring answers whether your service is reachable; response time monitoring answers how fast it is while it is up. The two come from the same check, so you never have to choose between them. Pair it with website monitoring to watch your customer-facing pages and with API monitoring to watch the services behind them. Every measurement flows into your incident history and onto the status dashboard, giving you availability and performance in one platform.
Frequently asked questions
What is response time monitoring?
Response time monitoring is the practice of measuring how long a website or API takes to respond on every check. MonitorUrs records the response time in milliseconds each time a probe runs, so you can track performance trends and spot slowdowns before they become outages.
How does MonitorUrs measure response time?
On every HTTP probe check, MonitorUrs records the response time in milliseconds alongside the HTTP status code and response body length. These per-check measurements are logged so you can review trends over time and see current values on the status dashboard.
Can MonitorUrs alert me when response time exceeds a threshold?
Probe alerts for websites and APIs fire on check failures after a configurable consecutive-failure threshold, not on a numeric latency value. Response time is measured and tracked for trend analysis. Server-side metric alert rules do support numeric thresholds with hysteresis for server metrics such as CPU or memory.
How often is response time recorded?
Response time is recorded on every probe check. Checks run on a configurable interval, with a default of every 15 minutes, so a new measurement is captured each time the probe runs.
Where can I see response time data?
Current response time values appear on the status dashboard, and the full per-check history is kept in the incident history so you can review how latency has trended over time.