ISOGrid platform status
The availability of the platform and its public clusters, measured every minute from the outside, with the month-by-month history and every incident. No customer data is identifiable in it.
Availability, SLO and health checks
For each calendar month (Algiers time), the share of time each component responded, whether the target was met, and how many health checks were made and failed. The current month is judged against the allowance for the full month.
Scroll the table horizontally to see all columns.
| Month | Platform | Public clusters | Web access | Health checks | Incidents |
|---|---|---|---|---|---|
| Loading… | |||||
✓ target met · ✕ target missed · – no measurement yet. The platform has been measured since October 1st, 2026; the clusters and web access, since September 2026. Until September 30, our customers’ private clusters were counted together with the public clusters.
Incidents of the last twelve months
An incident is opened automatically when the console, the API, sign-in or a public cluster fails two checks in a row, and closed after three successful checks. Nothing is filtered by hand.
| Status | Affected component | Start | End | Duration | Failed checks | Explanation |
|---|---|---|---|---|---|---|
| Loading… | ||||||
How we measure
- Platform: every minute, the console, the API and the sign-in service are called at their public address, over HTTPS, as a visitor would. Any response without a server error counts as available.
- Public clusters: the shared clusters on which our customers’ services run. A cluster is available when one of its managers responds. Private clusters, installed on our customers’ machines, are not counted.
- Web access: every address served by our web servers must resolve and get a response. The code returned by the customer’s application does not count.
- Health checks: a check is one component monitored for one minute. A minute we could not observe is counted neither as available nor as unavailable.
The same figures, live, are on the home page.