Service status
Service status and operating commitment
The operating commitment AIRAS Cloud is held to, the components it applies to, the role accountable for each, and the state observed right now. Nothing on this page is authored by hand: the objectives come from the service model the runtime alerts on.
Current state
Observed now
Reading current service state…
Uptime monitors should poll /api/public/status for the full projection or /api/public/health for a liveness probe. Both are unauthenticated, rate-limited and disclose no tenant data.
Service-level objectives
What we commit to, per component
Availability is stated over the measurement window shown. Latency is stated at the percentile shown. Acknowledgement is the time from alert to a named human owning the incident during supported hours.
| Component | Criticality | Availability | Latency | Acknowledge | Accountable |
|---|---|---|---|---|---|
| Application and web deliveryServing the AIRAS Cloud application, public site and authenticated workspace. | Essential | 99.5%30-day rolling | p95 ≤ 800 ms | 30 min | Platform engineering |
| Governance data planeTenant-isolated storage for registers, assessments, obligations, decisions and audit records. | Essential | 99.5%30-day rolling | p95 ≤ 1000 ms | 30 min | Platform engineering |
| Authentication and access controlSign-in, multi-factor enforcement, role resolution and tenant membership checks. | Essential | 99.5%30-day rolling | p95 ≤ 1200 ms | 30 min | Security operations |
| Integration API v1Token-authenticated intake of candidate systems and export of the obligation register. | Essential | 99.0%30-day rolling | p95 ≤ 1500 ms | 60 min | Platform engineering |
| ARIE regulatory engineDeterministic, digest-bound scoring and trace generation under a locked ruleset version. | Essential | 99.0%30-day rolling | p95 ≤ 2000 ms | 60 min | Governance office |
| Document safety gateStructural inspection and malware refusal for uploaded governance evidence. | Supporting | 99.0%30-day rolling | p95 ≤ 5000 ms | 120 min | Security operations |
| Release provenanceBinding the running runtime to an exact authorised commit, artefact digest and configuration fingerprint. | Essential | 99.9%90-day rolling | p95 ≤ 500 ms | 30 min | Service owner |
Escalation
What happens when an objective is missed
Severity is assigned by the service model, not by judgement at the time. An unreported essential component is treated as degraded, never as healthy.
- Acknowledge 30 min
Severity 1 — service unavailable
An essential component is down. Incident opened, responder paged, status page updated, customer notification issued and a post-incident record produced.
- Acknowledge 60 min
Severity 2 — essential capability degraded
An essential component is degraded or not reporting. Incident opened and worked continuously; status page updated when customer-visible.
- Acknowledge 240 min
Severity 3 — supporting capability or objective breach
A supporting component failed, or a latency objective was breached while the component still answered. Logged, owned and remediated within the next working cycle.
AIRAS Cloud does not currently claim 24×7 operations. Supported hours, contractual service credits and incident communication targets are set in the service-level schedule issued with an order form.
Reviewing AIRAS Cloud for enterprise deployment?
The Trust Centre holds the control register, test evidence and delivery governance record behind this operating commitment.
No commercial commitment. No confidential information required.