Business continuity

A business continuity page is usually a promise. This one is an inventory: for each kind of failure, what is in place, and what has been rehearsed rather than merely configured.

The failures, and what stands between you and them

Failure	What is in place	Rehearsed?
One Azure availability zone becomes unavailable	Zone-redundant database with a standby in a different zone, read as Healthy	Not rehearsed by us — failover has not been staged
Data is lost or corrupted (bad import, bad migration)	Point-in-time restore	Yes — drill run end to end, result PASS
A merchant damages their own data	Merchant-initiated backup and restore	Not separately drilled
The platform stops responding	Five alert rules with an action group	Yes — an alert was provoked and observed firing, Sev 1

The “rehearsed?” column is the one worth reading. Everything in the second column is real; only two of the four have been put under load on purpose.

What happens during an incident

1. Detection. An alert fires against the platform metrics — see Monitoring & alerting.
2. Assessment. The failure is classified: automatic recovery (a zone failover), data recovery (a restore), or a fault that needs a fix and a deploy.
3. Recovery. For data loss, the point-in-time restore path is the one that has been drilled. The drill produced a finding worth repeating here: a restored database server does not inherit the original’s firewall rules, so restoring the data is not the last step.
4. Afterwards. The cause is written down where it is measurable rather than described, so the next occurrence is recognised rather than rediscovered.

Recovery numbers — capability, not a commitment

These are measurements of what today’s setup allows. They are not a service level agreement: CIQRA does not publish one, and printing “our RTO is X” would manufacture a promise out of a capability.

What	Measured	Where it comes from
Data-loss window (RPO)	≤ 5 minutes with point-in-time restore	Continuous write-ahead-log archiving on Azure Flexible Server

| Restore horizon | point-in-time restore retention is set to 35 days. Effective coverage grows with server age and reaches the full 35 days on 6 September 2026 | Measured 9 August 2026: 6.7 days — backup.earliestRestoreDate = 2026-08-02T12:34:59Z, server createdAt = 2026-08-02T12:29:30Z | | Off-region backup copy | Enabled | geoRedundantBackup | | Database recovery (RTO) | in-region takeover in 60–120 seconds | The platform’s high-availability configuration | | Application recovery | container revision rollback in ~2 minutes | Timed during a real recovery on 9 August 2026 |

Why the restore horizon is written as a mechanism and a date, not a number

Three different numbers were in play here, and they are not three versions of one fact:

• 30–35 days — what our published legal terms promise.
• 35 days — what the retention setting is configured to.
• 6.7 days — what was actually restorable on 9 August 2026. The server itself was created on 2 August 2026, so the backup window has only had a week to accumulate; it grows by a day each day until it reaches the configured 35.

Only the third one answers “how far back can you actually go”, and it is different tomorrow. Writing any single figure into this row would have been wrong on some day: 35 is a lie today, 6.7 is a lie next month. So the row states the setting, the mechanism, the measurement and the fields it was read from — which stays true as the window fills.

🔑 A fixed number cannot describe a moving fact. That is not a wording preference; it is the same failure as an honest sentence that goes stale because the product moved underneath it.

Read those last two rows carefully, because we have:

The two rows that are weaker than they look

The 60–120 second figure is the platform provider’s stated behaviour, not our measurement. We measured a return to service after a change (91 seconds) — which is not the same event as a zone takeover, and the difference has not been measured.

No failover has been rehearsed. The high-availability configuration reads as healthy, and “healthy” is a status report, not a test. Until a takeover has been staged and timed, we will not describe it as tested.

The one recovery path that has been rehearsed end to end is the point-in-time restore, and its result is above: PASS.

What this page does not say

• It does not claim a tested failover between availability zones. The configuration is read as healthy; a staged failover has not been performed.
• It does not describe network-perimeter protections. That has not been measured for publication.