Sentry uptime
Sentry, checked by StatOSS every 5 minutes from Aarhus and Copenhagen in Denmark, Falkenstein in Germany, Ashburn in the USA, Singapore, and Sydney in Australia. Measured from outside, with every outage dated in UTC.
Sentry is up.
Up for 4 d 16 h. Last checked 2026-10-06 11:38 UTC from Sydney, Australia: 200 in 460 ms.
Last 24 hours
Up for 4 d 16 h100% passed
288 checks, median 162 ms from Falkenstein, all passed
95% under 182 ms
Response time by region
Medians over this range, on one scale up to 800 ms. Europe's places are scaled to Falkenstein, its fastest shared place.
Last 90 days
Up for 4 d 16 h99.60% passed
1,764 checks, median 161 ms from Falkenstein, 7 timeouts
95% under 188 ms
Response time by region
Medians over this range, on one scale up to 500 ms. Europe's places are scaled to Falkenstein, its fastest shared place.
In the last 24 hours Sentry passed 288 of 288 checks, 100%.
One outage since 30 Sep 2026, lasting 10 min, on 1 Oct 2026.
Availability
The share of checks that passed, and the outages that began, in each window up to now.
| Last | Passed | Checks | Outages |
|---|---|---|---|
| 24 hours | 100% | 288 of 288 | 0 |
| 7 days | Not enough history yet: checks began on 30 Sep 2026 | ||
| 30 days | Not enough history yet: checks began on 30 Sep 2026 | ||
| 90 days | Not enough history yet: checks began on 30 Sep 2026 | ||
A year of checks is kept; the year's figure appears here once there is a year of them.
Response time by location
Over the last 7 days, from the checks that passed: the time from the start of the request to the answer's headers, with the DNS lookup, the connection and TLS included.
| From | Median | 95th percentile | Mean | Checks |
|---|---|---|---|---|
| Falkenstein, Germany | 161 ms | 191 ms | 314 ms | 194 |
| Ashburn, USA | 131 ms | 220 ms | 185 ms | 561 |
| Copenhagen, Denmark | 218 ms | 261 ms | 244 ms | 169 |
| Singapore | 298 ms | 948 ms | 368 ms | 557 |
| Sydney, Australia | 433 ms | 575 ms | 522 ms | 84 |
| Aarhus, Denmark | 190 ms | 218 ms | 265 ms | 192 |
Outages
Every outage in the last year, newest first. Times are UTC; what failed and where are kept for 14 days.
| Began (UTC) | Ended (UTC) | Length | What failed | Seen from |
|---|---|---|---|---|
| 10 min | Timed out | Singapore |
What is checked
Error tracking and performance monitoring: SDKs in apps send errors and traces there.
StatOSS sends GET https://sentry.io/api/0/ and counts the check as passed on status 200 within 10 seconds. The root of the web API on sentry.io, which answers 200 with its version and no token.
SDKs send events to separate ingest addresses, which are not checked; events can be taken in while the web app is down, and the other way round.
Sentry reports its own incidents at status.sentry.io. The figures here are measured from outside and can differ from it in both directions.
How it is measured
- One check every 5 minutes, from one location at a time in turn: Aarhus and Copenhagen in Denmark, Falkenstein in Germany, Ashburn in the USA, Singapore, and Sydney in Australia.
- A check fails when no answer comes within 10 seconds, when the connection or TLS fails, or when the answer is not status 200.
- A failed check is repeated at once from a second location, and counts only when that location fails too, or cannot answer within 20 seconds.
- Two failed checks in a row make an outage, dated from the second, and the first check that passes ends it. A failure shorter than 10 minutes may not make one, and times are good to about 5 minutes.
- Availability is the share of checks that passed. There are no maintenance windows: every check counts.
It is the same check a StatOSS status page runs for its owner, with the same rules; the docs on checks have the details.