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.
• That offsite copy cannot be used yet. Azure restores it only inside Sweden South, and Microsoft admits subscriptions to that region on request. The copy cannot be restored until Microsoft opens Sweden South to our subscription; until then, losing the whole of Sweden Central would leave the measurement backup kept but out of reach.
• 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.

The account database

Everything above is about measurements. The account database — sign-ins, tag definitions, API keys, alert rules and saved charts — is a separate Azure database with backups of its own. Azure keeps point-in-time backups of it for 35 days, so it can be put back to any moment in that window after a mistake or a corruption; those backups are kept in Sweden Central, the same region as the database.

Outside the region there is a daily copy. Every day at 04:30 UTC the whole database is exported, the export is restored into a separate test database and checked table by table against the original before it counts, and it is kept for 35 days in geo-redundant storage whose second copy is in the paired region, Sweden South. Losing the whole region would lose the changes made to the account database since that copy — up to a day. That copy can be read from Sweden South today, with nothing asked of Microsoft first; the database would be restored from it onto a new server outside Sweden, a step written down but not yet rehearsed.

Where it is stored, and what leaves Sweden

Measurements and the account database are stored in Azure Sweden Central, and so are the vault that holds the nightly measurement backup and the storage that holds the daily copy of the account database; being geo-redundant, both keep their offsite copy in the paired region, Sweden South. There is no region to choose; this is the only arrangement. We do not send your measurement data outside Sweden — it leaves only when you read or export it, or when an alert you set up carries a value to where you told it to go: your email, a push or chat service you connected, or a webhook of your own.

Two services outside Sweden are ours to choose. Email — sign-up and address confirmations, password resets, invitations, account notices, and the alerts you have sent by email — goes through Resend, which processes it in the United States; it carries your email address and the content of the message, which for an alert includes the tag's name and the value that triggered it. Payments for the paid plans are handled by Stripe, on Stripe's own checkout and billing pages. The privacy policy names both, and what their transfers rest on.

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. One restore path has been rehearsed: on 20 October 2026 the account database's daily copy was restored from its copy in Sweden South and every table matched. Restoring measurements, or the account database to an earlier moment, within Sweden Central is written down and its commands are checked against the current Azure API; standing the account database up on a new server from its daily copy is written down; restoring measurements after losing the whole region waits on Microsoft (above). None of them has 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 those drills have been run, the measured times go 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. Export everything, in Settings, builds one archive of your account's data — every tag's readings at full resolution for your plan's window, its hourly and daily summaries, tag settings with former names, alert rules, notification channels and chart views — as CSV or Parquet, with a README that explains every file; the alerts your rules raised and the team's users come from the API instead. It is built in the background — minutes for most accounts, hours for the largest, longer if another account's export is being built first — we email you when it is ready, and it can be downloaded for 7 days. A tag at a time, measurements, aggregates and tag metadata also export straight from the API as Parquet, CSV or JSON. There is no export fee. See how long data is kept.