All systems operational.
Live status for every major MediVault component, our uptime history against the contractual SLA, and a factual record of what has gone wrong — including what we changed afterwards.
- Uptime this month
- 99.997%
- Trailing 12-month uptime
- 99.994%
- Open incidents
- 0
- Mean time to recovery
- 38 min
Illustrative sample data — MediVault Zürich is a demonstration site. The metrics, incidents and maintenance windows on this page are fictional and shown for portfolio purposes only.
The console our on-call
engineers actually watch.
Every figure on this page — this month's uptime, the 90-day history, the incident log below — is the same data shown on a console like this one, on a demonstration data set rather than live production telemetry.
- 99.997%
- Uptime this month
- 90 days
- History shown
- 10
- Components tracked
- 38 min
- Mean time to recovery
Ten components,
checked continuously.
Each row reflects the current state of a distinct production component, not an aggregate. A single degraded dependency is shown as degraded — it is never rolled up into a green summary.
HL7 FHIR R4 read/write endpoints and OAuth 2.0 token issuance.
Browser workspace for clinical staff — patient search, records, uploads.
Primary production vault, Rümlang ZH — active read/write.
Glattbrugg ZH — synchronous replication target for the primary vault.
Replication lag briefly exceeded target during scheduled network maintenance at the Glattbrugg site. Auto-recovered within the RPO window; no data was at risk. Monitoring for 48 hours per standard procedure.
Meyrin GE — warm standby, 15-minute recovery point objective.
MFA, FIDO2, SAML/OIDC federation and SCIM provisioning.
Append-only, hash-chained, cryptographically signed audit event stream.
Signed webhook dispatch with replay protection and automatic retries.
Outbound event streaming to Splunk, Sentinel and QRadar.
Self-serve sandbox tenants with synthetic patient data.
Ninety days,
one bar each.
Each bar is one day. Teal is fully operational, amber is a degraded period, red is an outage. Hovering the underlying data with a screen reader announces the incident count for that component.
Measured against
a 99.99% SLA.
Trailing six months, platform-wide. Uptime is measured at one-minute resolution against the FHIR API and Secure Portal, the two components a clinical user depends on directly.
| Month | Uptime | Incidents | SLA target |
|---|---|---|---|
| March 2026 | 99.998% | 1 | 99.99% |
| April 2026 | 100.000% | 0 | 99.99% |
| May 2026 | 99.994% | 1 | 99.99% |
| June 2026 | 100.000% | 0 | 99.99% |
| July 2026 | 99.999% | 0 | 99.99% |
| August 2026 | 99.997% | 1 | 99.99% |
What went wrong,
stated plainly.
Every incident above informational severity, in full, including root cause and what we changed afterwards. Nothing here is edited for tone.
Elevated FHIR API latency, Zürich region
A misconfigured connection-pool limit on one API node caused p95 read latency to rise to roughly 900 ms for Patient and Observation reads between 09:12 and 09:59 CET. Writes were unaffected throughout, and no data was lost or exposed.
Resolution — The affected node was drained from rotation and the connection-pool limit corrected. A pool-saturation alert was added so the same condition now pages on-call before it affects latency.
Secure Portal authentication outage
An expired intermediate TLS certificate on the identity provider's edge caused new portal logins to fail between 14:03 and 14:25 CET. Sessions already established before the outage were unaffected.
Resolution — The certificate was renewed and rotation was automated with a 30-day expiry alert. The manual renewal step was removed from the deployment runbook entirely.
Webhook delivery delay
A routine dependency upgrade increased event-serialization time, backing up the webhook dispatch queue and delaying — not losing — roughly 4,000 events to 6 tenants.
Resolution — The serialization path was optimised and the dispatch worker pool scaled. All delayed events were redelivered and their receipt confirmed with each affected tenant.
Synchronous replication lag, ZH-DC-02
Scheduled network maintenance at the Glattbrugg site pushed inter-site replication RTT past threshold, degrading synchronous replication for 65 minutes. The primary vault (ZH-DC-01) remained fully available throughout.
Resolution — The maintenance procedure was updated to stage network cutovers during lower-traffic windows, and replication-lag alerting thresholds were tightened.
Every incident above P3 receives a written post-incident review within 10 working days, covering timeline, root cause and corrective action. See our incident response process.
Planned work,
announced in advance.
Maintenance is performed without customer-visible downtime wherever the architecture allows it — usually by failing traffic over to a healthy site before work begins.
ZH-DC-02 network firmware upgrade
Firmware upgrade on the Glattbrugg replica's core switching fabric. Traffic fails over to ZH-DC-01 for the duration; no customer-visible downtime is expected.
Identity provider certificate infrastructure migration
Migration to a new certificate issuance chain for SSO. Active sessions are unaffected; some users may be prompted to re-authenticate once. FHIR API and vault availability are unaffected.
Subscribe to
status updates.
We do not yet run a public status-subscription feed on this demonstration site. For production incidents or advance maintenance notices, reach the clinical support desk directly.
Production incidents, access issues and vault operations.
- support@medivaultzurich.site
- Phone
- +41 44 512 88 99
- Availability
- 24 / 7 / 365
Something not
adding up?
If what you are seeing does not match what this page reports, contact the clinical support desk directly — P1 issues are acknowledged within 30 minutes, 24/7.
Illustrative sample data for a demonstration site