Service status
What our own monitoring has measured, against the 99.5% we commit to. Read the second box before you rely on any of it.
What this page cannot tell you. It is served by the same machine it reports on, and the monitoring behind it is our own. Two consequences, and neither is hidden anywhere else on this site:
- If the box is down, this page does not load at all. A status page that goes down with the service is worth nothing during the outage it exists for. If this page failed to load, that is your answer, and it is the most reliable signal we can offer you.
- Nobody independent is watching. There is no third-party monitor checking us, which SLA section 4.1 states outright. These numbers are our own measurements, published because you should be able to see them without emailing us, not because anyone has audited them.
So: if you cannot reach this page, check whether inspekt.gg resolves and
whether your own embed or API call is failing too, then email
hello@inspekt.gg. We answer email on a machine that
is not this one.
Right now
| Surface | State | What it is |
|---|---|---|
| Loading |
Uptime against the commitment
Last 30 days
—
rolling, not what credits are computed from
Commitment
99.500%
per calendar month, UTC
Downtime this month
—
counted in whole 5 minute intervals
The commitment is measured per calendar month, so that is the number a service credit is computed from. The rolling 30 day figure is the answer to a different question, which is how it has been lately.
| Month | Uptime | Downtime | Observed | Credit if claimed |
|---|---|---|---|---|
| Loading |
Last 90 days
One bar per UTC day. Green is a day with no failed round, amber a day with at least one, red a day that was more down than up. A grey bar means no rounds were recorded that day, which means the monitoring was not running, not that the service was fine.
Recent incidents
- Loading
How this is measured
- A synthetic check runs against the public name every 5 minutes, exercising DNS, the forward, the proxy and TLS rather than just the origin on localhost.
- It probes the health endpoint,
/embedand/api/still. It does not probe the Inventory API, because a lookup calls Steam, and sending a third party 288 unsolicited requests a day to watch our own uptime is the behaviour our own Acceptable Use Policy forbids customers. - A round counts as down if a surface returns a server error or fails to answer within 30 seconds, which is the definition in SLA section 2.2. A 4xx counts as up: the service answered, and refusing a bad request is it working.
- Downtime is counted in whole probe intervals, so one failed round costs a full 5 minutes even if the blip lasted three seconds. That is deliberately pessimistic and it is the resolution the commitment is measured at.
- Percentages here are computed from the same rounds, by the same rule, as the tool that answers a credit claim. If this page and that answer ever disagree, this page is wrong.
What runs underneath
SLA section 3.1 says it in full and it is worth repeating here: Inspekt runs from a single self-hosted origin on a residential internet connection, with no automatic failover and no CDN in front of it. One hardware failure, ISP outage, power cut or local network fault takes the whole thing offline. The 99.5% figure was set with that in mind rather than in spite of it.