clouderra
Service status
State updates automatically from external probes. The machine-readable version is
/api/v1/status.
| Component | State | Availability, 90 days | Region |
|---|---|---|---|
| Copy intake | operational | 99.98% | Moscow, Amsterdam |
| Restore verification | operational | 99.7% | Amsterdam |
| Control panel | operational | 99.95% | Moscow |
| Restore data delivery | operational | 100.00% | Moscow, Amsterdam |
| CSV report export | delayed | 98.4% | Moscow |
Incident history
18 June 2026 — report export delay
After a new CSV format was enabled, the export-building queue stopped keeping up during peak hours. We capped the size of a single export and moved parsing of archived periods into a separate queue. Monitoring.
2 June 2026 — copy intake, 11 minutes
An intake upgrade in the Moscow region ended in a rollback: the new version mishandled resuming an interrupted transfer. Agents received a rejection during this time and retried automatically; no points were lost.
7 May 2026 — restore verification, 3 hours 40 minutes
The isolated environment for verification ran out of free space because results of previous runs hadn't been cleared. Scheduled verifications for that window were performed later the same day. We added a free-space check as a precondition for starting.
14 March 2026 — control panel, 24 minutes
One of the internal certificates used between the panel and the API expired. Copy intake and restore worked throughout: agents don't depend on the panel. Internal certificate expiry is now watched by the same alert as the external ones.
How we measure availability
Availability is measured per component, not per service as a whole, and by external probes from three points. A minute counts as unavailable if at least two of the three points agree it was — which filters out problems at a single observer.
Planned maintenance is not excluded from the calculation. If we stopped copy intake for ten minutes for an upgrade, those ten minutes are subtracted from availability like any others.