Durability is the promise your data is still there in five years. The big clouds quote it from replication math and round up. XNS computes it from each provider's measured risk — and holds the line with continuous active repair.
11 nines
Durability floor, actively held
80 + 40
Data + parity shards per object
120
Diverse providers per object
0
Replication — computed, not copied
Why eleven nines is usually a sleight of hand
Most cloud stores express durability as a percentage — 99.999999999%, “eleven nines.” With the big three it’s often a sleight of hand: figures derived from replication math and rounded up, leaning on “availability zones” that share more fate than the marketing admits. XNS has zero replication — so our eleven nines isn’t assumed from copies, it’s computed from each provider’s measured risk and provably held.
How the data is spread
Erasure coding chops data into pieces and adds redundancy pieces for durability. On the XNS distributed datacenter it’s applied at the client, creating thousands of slivers spread across a diverse set of providers — your Virtual Private Datacenter. Each object becomes 80 data + 40 parity shards across 120 providers. An object is lost only if more than 40 of its 120 shards are gone before repair.
80data shards40parity shards120providers per object>40lost before repair = only failure
We don’t wait for failure
When providers weaken, the fix is to remake fresh slivers and place them on stronger providers — Active Repair, running on the network today.
Every provider earns a The moment loss probability approaches the line — one minus eleven nines — it re-uploads, migrating data off weak providers until risk falls back below the limit. Eleven nines isn't a launch-day snapshot; it's a floor we actively hold.life_expectancy from its real history — contract-renewal failures and Merkle-proof results. The repairmonitor module converts that into each provider's probability of data loss, aggregates risk across your whole dataset, and recomputes it every cycle — 48 hours by default.
Show your work
We don't claim eleven nines by analogy to replication. We compute it — from each provider's measured risk, on a repeating cycle — and hold the line with active repair. Every provider earns a Life-Expectancy score from its real history — contract renewals and Merkle-proof results. That becomes Pe: the probability it loses your shard before we repair it. No two providers are assumed equal. The chance that exactly K of N providers fail would be the binomial term: Those coefficients CKN are Pascal's triangle — each cell the sum of the two above it: We build the failure distribution one provider at a time with the Poisson-binomial recurrence, folding each in with its own Pe: With 80 data + 40 parity across 120 providers, an object is lost only if more than 40 of its 120 shards fail before repair. Durability is one minus that tail: Repairmonitor recomputes this probability every cycle. The moment an object's loss probability approaches the line — one minus eleven nines — it re-uploads fresh slivers and pulls the risk back down. Eleven nines isn't a launch-day snapshot; it's a floor we actively hold. That's the difference. The big three quote durability from replication math and round up. We quote it from each provider's measured risk — and keep it there. Algorithm (Poisson-binomial "at least N events"): github.com/starius/nevents.1Each provider carries its own risk
2If every provider were identical
1
1 1
1 2 1
1 3 3 1
1 4 6 4 1
1 5 10 10 5 1
1 6 15 20 15 6 1
1 7 21 35 35 21 7 1
3They aren't identical — so we use the real distribution
4Your object survives unless parity is overrun
5 · Goalseek — we don't wait for failure
The numbers behind the number
Parameter Value Where it comes from Data shards per object 80 Reed-Solomon, set per price group; 80+40 is the deployed configuration, not a compiled-in constant Parity shards per object 40 as above — an object survives until more than 40 of its 120 shards are gone Providers per object 120 one shard each Target durability 0.99999999999 the shipped default of the repair target, HOSTIO_REPAIRS_TARGET_DURABILITYHorizon the figure covers 360 hours 15 days — HOSTIO_DURABILITY_STOR_DURATION_HOURS. Read the next section before comparing this to an annual figureRecompute and repair cycle 48 hours HOSTIO_DURABILITY_CALCULATION_INTERVAL
Each provider's chance of losing your shard inside the horizon comes from an exponential survival model. R is that provider's measured remaining life expectancy, earned from its own contract-renewal and Merkle-proof history; T is the 360-hour horizon: Pe = 1 − e−T/R Two cases are deliberately pessimistic rather than optimistic. A provider with no measured history is assigned Pe = 1 — counted as already lost. So is any shard that was written during an earlier run of a provider that has since restarted its life. Unknowns count against the number, never for it.
The formula above is only worth as much as the number you can put through it, so here is the number. Hold every provider at the same Pe and the Poisson-binomial collapses to a plain binomial over 120 shards, losing the object at 41 failures. That makes eleven nines a threshold you can check rather than a claim you have to accept: Read the highlighted row. Eleven nines over 15 days holds as long as each provider's chance of losing its shard inside that window stays at or under 10.87%. Put through the survival model, that is a measured remaining life expectancy of about 3,130 hours — roughly 130 days per provider. Below that line the repair cycle re-places shards on stronger providers until the number comes back. Every figure in this table is a binomial tail you can reproduce; nothing here is fitted or rounded up.If each provider's Pe is… …chance of losing an object Nines 5% 2.0 × 10−23 22.7 8% 3.9 × 10−16 15.4 10% 6.8 × 10−13 12.2 10.87% 1.0 × 10−11 11.0 12% 2.2 × 10−10 9.7 15% 1.5 × 10−7 6.8
where the model stops being true
A durability figure is only as good as the assumptions under it. Ours are printed here, in full, so you can decide for yourself whether they hold for your data. No other storage vendor publishes this section.
The recurrence treats provider failures as independent. Real ones sometimes are not — shared facilities, a common software version, or an economic shock can take several providers together. Diversity of the provider set is what limits this, not the arithmetic, and the arithmetic will not warn you when it stops holding. Placement draws from one pool of host contracts rather than a pool per customer, so a single contract can hold shards belonging to many objects and many customers. A contract failure is therefore a small loss spread wide rather than a total loss for one object — but it means object outcomes are not fully independent of one another either. Eleven nines is the line the repair cycle drives toward and re-checks every 48 hours, so between recomputes the figure is a forecast rather than a reading. The forecast is only as good as available repair capacity: if there were no healthier providers to move a shard to, the real number would sit below the line until there were. The figure covers the next 360 hours because that is the window the repair cycle can hold and re-check against live data. An annual durability number is a projection made once and carried for twelve months; this one is recomputed from each provider's current measured history 24 times inside that same year. Two different quantities — ours is the one that gets tested. The horizon is set by what the data supports. At 80+40, holding the line over a full year would require every provider to carry 8.7 years of measured remaining life expectancy. Over 15 days it requires 130 days — a threshold real providers meet, which is why the figure is re-established rather than assumed. Independent review: none yet. The model, the parameters and the code that runs them have not been audited by an outside party. When that changes this page will say who did it and link what they published. Until then, the derivation above is the whole basis for the claim, which is exactly why it is printed here instead of summarized.Correlated failure is not in the model
Shards share a contract pool
Repair has to outrun loss, and it is measured doing it
Re-verified every cycle, not modeled once a year
Get keys, change one endpoint, and store on a network whose durability you can watch — and verify.