Status
See measured uptime and p50 and p95 latency per region for the public endpoints, with the incident history kept.
Uptime, last 30 days
99.22%
Below target255 probes in the last 24 hours
- Uptime, 24 h
- 99.22%
- p50 latency
- 589 ms
- p95 latency
- 867 ms
- Target
- p95 < 80 ms
By region
Uptime over 24 hours and 30 days, median and 95th percentile latency, one row per endpoint.
Colo BOMBOM
| Endpoint | 24 h | 30 d | p50 | p95 | Last 24 hours |
|---|---|---|---|---|---|
| /api/v1/ip | 100.00% | 100.00% | 654 ms | 856 ms | |
| /ip | 100.00% | 100.00% | 589 ms | 836 ms | |
| /json | 100.00% | 100.00% | 630 ms | 867 ms | |
| /json?full=1enrichment | 43.14% | 43.14% | 1195 ms | 1640 ms | |
| v4 /json | 98.04% | 98.04% | 85 ms | 97 ms | |
| v6 /json | 98.04% | 98.04% | 92 ms | 121 ms |
Take the badge
[](https://whatsmyip.fyi/status)What is measured
Probes run against the edge-only endpoints, /ip, /json, and /api/v1/ip, and separately against the enrichment path with ?full=1. Splitting them keeps a slow third-party provider from being reported as a slow service, and keeps a genuinely slow edge from hiding behind a provider excuse.
The target for the edge-only endpoints is p95 under 80 ms measured at the point of presence. That figure appears here as measured, not as an aspiration.
Why we run the probes ourselves
An external monitoring service would be more independent, and we may add one. What matters more for honesty is that the incident history stays intact and that the measurement method is described, because an uptime figure whose method is secret is not a figure at all. Both are on this page.
Using it in the comparison
/compare/ip-apis says plainly that this service is new and that established alternatives have a track record we cannot match. This page is where you check that for yourself before depending on us. A month of good numbers is a month of good numbers, and it is not a decade.
Generated 2026-09-05T19:37:18.028Z.
About this tool
A scheduled worker requests the public endpoints from each probe region on a fixed interval and records the response code and the elapsed time. The page reports uptime and p50 and p95 latency per region over several windows. We run the probes ourselves and say so. Incidents stay on the record with their duration and cause, because an uptime figure with no visible incident history cannot be checked.
How to read the result
- Uptime percentage
- The share of scheduled probes that returned a 2xx response within the timeout, per region and per window. A probe that times out counts as a failure even when the fault was in the probe's own network, so the figure is conservative.
- p50 latency
- The median response time, so half the requests were faster. It describes the typical experience and is insensitive to a few slow outliers, which is what makes it the wrong number to set a timeout against.
- p95 latency
- Ninety-five percent of requests completed within this time, which makes it the number to use for a client timeout, because the median hides the tail entirely. Our target is under 80 ms at the edge without enrichment.
- Per-region rows
- Latency is dominated by distance to the nearest point of presence, so different numbers per region are expected and are not a fault. A region that drifts away from the others over time is the signal worth looking at.
- Enrichment endpoints measured separately
- Endpoints that call an external provider are reported apart from the edge-only ones. They are slower by design, and mixing them into one figure would hide both the edge performance and any provider problem.
- Incident history
- Past incidents stay listed with their duration and cause. Removing them would make the uptime figure meaningless, because a perfect record that nobody can check is worth nothing.
Questions people ask
- How is uptime measured?
- A scheduled job requests the public endpoints from each probe region on a fixed interval, records the status code and elapsed time, and writes the result to a database. The page reads those records. It is external measurement in the sense that it is automated and continuous, and internal in the sense that we run it, which is stated rather than obscured.
- Why does this page show numbers instead of an uptime guarantee?
- Because a guarantee from a free service with no contract behind it is decoration. Measured numbers with a visible incident history can be checked. If you need a contractual commitment, this is not the right service to build on, and the comparison page lists alternatives with larger operators behind them.
- What counts as an outage?
- A probe that gets a non-2xx response or no response within the timeout. Partial degradation, such as enrichment being unavailable while the core endpoints serve normally, is recorded as a separate incident rather than as downtime, because the endpoints most clients depend on kept working.
- Can I use the status data in my own monitoring?
- There is a badge SVG endpoint for embedding in a README, and the raw figures are available through the API. Do not poll the badge on a short interval; it is a picture, and the API is the correct interface for automated checks.
- The site is down for me but this page says everything is fine. What now?
- Check /reachability-check from your own browser first, since a local network or DNS problem produces the same symptom. If several regions here show green while you cannot connect, the fault is between you and us rather than at the service, and traceroute will usually show where.
Related
Last reviewed 2026-09-05.