Where your data lives

The two numbers

What an acknowledgement means

A 2xx from the ingest endpoints means the measurement is committed to Azure Storage, replicated three times within the Sweden Central datacentre. Not received. Not queued. Committed.

This is stronger than it sounds, because the ordinary way to build an ingest path is to acknowledge from an in-memory buffer and flush on a timer — which means a crash quietly eats whatever was in the buffer, and the client was told it was safe. That was the behaviour here until August 2026, it was caused by a single wrong null-coalescing operator, and it was fixed and then verified causally rather than assumed: a batch answered 200 while the durable log segment grew by 613 bytes in the same moment.

The converse matters as much: a request that was never acknowledged may be lost and must be retried by the client. A 503 or a 429 means nothing was stored, so a retry is always safe and never creates a duplicate.

The nightly backup

• Measurement data is backed up nightly at 01:30 UTC to an Azure Recovery Services vault.
• The vault is geo-redundant, which places the offsite copy in the paired Swedish region, and cross-region restore is enabled.
• An offsite recovery point was verified on 10 August 2026 — verified as the vaulted copy specifically, not merely an in-account snapshot. The distinction matters: a snapshot lives in the same storage account and dies with it, so if the account is what you lost, only the vaulted copy helps.

Everything stays inside Sweden. Data residency is not a configuration option here; it is the only arrangement.

What we deliberately do not claim

Three things a vendor page would normally assert, which this one will not until they are true and measured.

• No recovery time objective. The restore procedures are written down and their commands are checked against the current Azure API, but they have not been rehearsed end to end against real data. A runbook that has never been executed is a hypothesis, not a procedure, and a recovery time nobody has measured is a number we would be inventing. When a drill has been run, the measured time goes here.
• No uptime SLA and no uptime percentage. Free, Pro and Business are self-service plans on a best-effort basis, with no service credits. A contractual SLA exists only under a negotiated Enterprise agreement. We do not publish an availability figure because we have not been running long enough to have measured a meaningful one.
• No customer counts and no logos. There are none worth quoting yet, and borrowed credibility is the cheapest kind.

The part we cannot promise anything about

If you ingest through the MQTT or OPC UA collector, there is a link in the chain that is on your side of the internet, and it has a ceiling.

The collector's on-disk queue holds readings while the uplink is down and is bounded at 7 days or 512 MiB, whichever comes first. Past either, the oldest records are evicted. The API can promise that nothing it acknowledged is ever lost; it cannot promise anything about samples that queue dropped before they were ever sent.

For a long planned outage, raise those limits in the collector config beforehand, or plan to backfill from the source system afterwards.

When we are the one under pressure

Two different refusals, because they mean two different things and blaming the wrong party is how clients end up retrying the wrong way.

Both carry Retry-After, with jitter — otherwise every collector on the planet would retry in lockstep. And batches are all-or-nothing on the batch endpoint: partial admission behind a 200 is the original problem wearing a new hat, telling a client that a thousand readings landed when four hundred did.

Getting out

The last durability question is the one about us rather than the hardware: what happens if you want to leave. Measurements, aggregates and tag metadata all export as Parquet, CSV or JSON, with no export fee and no retrieval delay. See how long data is kept.