Service status
Loading current status…
| Service | Current state | Availability | Avg response | Last checked |
|---|---|---|---|---|
| Loading… | ||||
How this is measured
Every figure on this page comes from a synthetic monitor that we operate and whose records we retain. It probes each surface on a fixed interval and records the outcome to an append-only log. Nothing here is estimated, inferred from an error rate, or taken from a provider dashboard.
- Loading methodology…
Why a page can be “up” and still be counted as down
A check that only reads HTTP status codes cannot tell a healthy page from a broken one that still answers 200 — a blank template, a stale build, or the wrong site served on the right hostname all return success. So every probe also asserts that a specific piece of expected content is present in the response body. If the content is missing, the probe is recorded as a failure regardless of the status code.
This is the single most common way uptime numbers flatter a vendor, and excluding it is the reason these figures are lower than a status-code-only monitor would produce.
What this page does not tell you
The probes run from the same global edge network that serves the sites. That makes them a good test of whether the application is healthy, and a poor test of whether a particular visitor could reach it — an outage confined to one network path or one region may not appear here at all. We would rather state that limitation than present the measurement as more complete than it is.
This page also reports availability, not correctness. A service can be fully available and still be wrong; incidents of that kind are handled under the severity definitions in the service level agreement.
Reporting an outage
If you can see a problem that this page does not, that gap is itself worth knowing about. Contact support@omegapointsolutions.com, or for procurement and contractual questions, contracting@omegapointsolutions.com. Response and restoration targets are set out in the service level agreement.