# Website latency and regional response-time monitoring Source: https://pingy.io/features/latency Find where the wait begins. A website can stay online while getting slower. Pingy tracks response times from your selected check regions and puts the history beside recent request details. Compare locations, examine a slowdown and separate connection delays from a slow first response. ## 12 global monitoring stations Choose check locations across the Americas, Europe, Africa and Asia Pacific. The number of locations per site depends on your plan. - US East (NC) - France (Paris) - Australia (Sydney) - Japan (Tokyo) - Brazil (São Paulo) - US West (CA) - South Africa (Johannesburg) - US Central (Chicago) - Spain (Madrid) - Netherlands (Amsterdam) - Singapore - India (Mumbai) [Current station status](https://pingy.io/status) ## Measure the stages of the request For HTTP checks, the response-time measurement is time to first byte: elapsed time from the start of the request until the response begins. Supporting timings break out DNS lookup, connection and TLS setup when the collector supplies them. Some regions or failed requests may have only part of the breakdown. ### DNS lookup Time spent resolving the hostname in the request timing data. Investigate a slow lookup before attributing the delay to your application. ### TCP connection Connection time after subtracting the DNS lookup component. Spot delays establishing a connection to the selected server. ### TLS handshake TLS setup time after the TCP connection, where an HTTPS handshake is measured. Review a change in HTTPS negotiation independently of the initial connection. ### Time to first byte Elapsed time until the first response byte, including the earlier connection stages. Compare response latency across regions. This is not a measurement of application processing alone. ### Total request time Elapsed time through completion of the collected request. Compare time to first byte with the full transfer. Do not add cumulative TTFB to the earlier stages. ### Downloaded bytes The response size reported by the collector when available. Give a longer transfer context: a larger response can take longer after the first byte. ## Compare locations over time The dashboard offers 24-hour, 7-day and 30-day views. Each regional series can be inspected against the others, with a location map and a table of recent results. When history is shorter than the selected range, the chart uses the available data so a new monitor remains readable. ### Regional response-time series Timestamped response-time history grouped by check location. Separate a regional pattern from a slowdown seen across all selected regions. ### p50 and p95 Percentile summaries calculated from the response-time averages plotted in the dashboard. Compare the middle and slower end of the displayed distribution. These are not raw visitor or raw request percentiles. ### Slowest region The slowest region in the displayed comparison. Choose where to start investigating a geographic difference. ### Latest region status Each check location's last result and measured response time. Read a spike alongside its HTTP result and collection time. ### Availability and incidents Recorded uptime, failures, recoveries and open incidents. Separate slow successful responses from periods when requests could not complete. ### History export and change markers Exportable plotted data and monitoring events alongside the chart. Share the relevant interval and compare timing with changes. Nearby events alone do not establish a cause. ## Read the response behind a data point A latency number becomes more useful when you know what answered. Open the recent checks to inspect the HTTP response, destination and failure information. A redirect to a login page or a firewall response can be fast while still being the wrong result for your intended visitor. ### HTTP status code The response code returned by the check. Distinguish a normal response, a client-side denial and a server error. Reachability alone does not prove the expected page worked. ### Resolved server IP The address reached by the request when available. Look for a changed origin or a different destination between checks. ### Redirects and final destination Redirect count, final URL and final hostname. Identify extra hops or requests ending at an unexpected service. ### Failure layer and error Collected DNS, TCP, TLS or HTTP failure context. Start with the stage that failed instead of treating every timeout as a website-code problem. ## Keep a picture of what loaded Pingy also captures timestamped website screenshots. They provide visual context for a maintenance page, an error screen or a page that renders differently after a deployment. Screenshots have their own capture time; they are not generated for every regional uptime request. A request timing check does not render the whole page, run a browser performance audit or measure Core Web Vitals. Use the screenshot to inspect appearance and a browser performance tool when you need JavaScript, layout or real-user experience measurements. ## Investigate a regional slowdown Choose the interval that contains the change and compare the affected region with the others. Open recent checks for the same period. A rise in connection time suggests a different starting point than an unchanged connection followed by a longer wait for the first byte. Check the resolved IP, redirects and HTTP status before changing application code. A CDN routing change or firewall challenge can change the path or response. Export the chart data when sharing the incident with a hosting or network provider. ## Scheduled monitoring Check frequency and region count follow the plan selected for each site. Free provides hourly, best-effort checks from one location. Pro and Enterprise support faster checks and multiple selected regions; see the current plans below. A public free check is a point-in-time result, not a historical monitoring series. ## Is response time the same as page load time? No. HTTP response time measures the wait for the first byte. A browser still has to download assets, execute JavaScript and render the page. Pingy screenshots provide separate visual evidence. ## Can I compare a new monitor over 30 days? You can select the range, but the chart can only show collected history. Missing historical data is not fabricated. ## Can Pingy warn me about sustained slowdowns? Paid monitoring includes sustained-slowdown detection. Review latency history and the related checks when investigating an alert, and configure notification channels in account settings. [Request timing reference (curl)](https://curl.se/libcurl/c/CURLINFO_NAMELOOKUP_TIME.html)