The redirect is the promise. Here’s how it holds.

1. 01

   The short version

   The one thing that has to keep working is the redirect — the jump from a scanned code to its destination. QRever is engineered so that path has the fewest possible moving parts, keeps resolving through a brief outage, and, if the company itself ever disappeared, could be replaced by a code you already hold.

   This describes the system as of 2 September 2026.

2. 02

   How a scan resolves

   When someone scans a dynamic QRever code, their phone opens a short URL like qrever.com/r/x7k2p. That request is handled by an edge function running in the region nearest the scanner, with a target under 100 milliseconds:

   • The code’s current destination is looked up from a cache held at the edge. The cache entry is invalidated the instant you edit the destination, so an edit is live everywhere within seconds — but a routine scan never waits on the database.
   • The visitor is sent on with an HTTP 302 to your destination, or to the hosted page for a QR Page.
   • The scan is recorded after the redirect is issued, as a background task. Analytics never sit between the scan and the destination.

   Every failure mode has a defined response: a code that was deleted by its owner returns 410 Gone with an explanation, a code that never existed returns 404, and a transient lookup error returns 503with a small branded page — never a blank error or an infinite spinner.

3. 03

   Uptime, stated honestly

   We target high availability and design for it, but we do not publish a contractual uptime SLA — QRever is run at a deliberately small scale and sells no enterprise contracts that such a number would back.

   What we can say concretely: the redirect path depends on Vercel’s edge network and a cached lookup, and nothing else. It has fewer dependencies than the dashboard, and it is the part built to stay up when other things wobble. Both platforms we run on publish their own real-time status pages.

4. 04

   Backups

   The database is backed up automatically every day by Supabase, encrypted, and retained on a rolling window. Uploaded images are stored redundantly by the same provider. Our application code and the full database schema are in version control, so the running service can be reconstructed from source at any time.

5. 05

   Recovery

   Component failures — a bad edge region, a database node — are absorbed by the managed platforms without our involvement. A larger loss is recovered by redeploying from version control and restoring the latest database backup.

   The recovery objective that matters is the redirect: destination data is small and changes rarely, so restoring the ability for codes to resolve is the fastest part of any recovery, not the slowest.

6. 06

   The static fallback

   Every dynamic code can be converted, from your dashboard, into a static fallback: a brand-new QR that encodes your current destination directly into the pattern. It works with no redirect, no servers, and no QRever — scanning it goes straight to the URL.

   It is available from the day you create a code, not just in an emergency. If you ever stop trusting any hosted redirect — ours or anyone’s — you can print the fallback instead and walk away. A hosted QR Page runs on our servers and cannot be reduced to a static QR; its continuity comes from the full-content export below.

7. 07

   Export

   Every paid code has a one-click export — the short ID, the full history of every destination it has pointed at, the complete scan log as CSV, and, for a QR Page, all of its content. No request form, no waiting period. The exact contents are documented on the data export page.

8. 08

   If QRever ever shuts down

   This is the formal procedure, and it is also written into our Terms of Service:

   • Account holders receive at least 30 days’ advance notice by email before the service closes.
   • Throughout that window, the dashboard, the export, and the static fallback generator all stay available, and every code keeps resolving normally.
   • No code is ever flipped to a “deactivated” state — that state does not exist. Codes simply keep working until the notice period ends.
   • No refund is issued solely because the service closes. The export and the static fallback are the continuity guarantee, and they are provided from day one specifically so a refund is not the remedy.
9. 09

   Why this is credible

   The escape hatches are not a closing-time promise — they are generated for every code, every day, and any customer can test them right now. QRever’s entire business model is a single payment followed by a recommendation to a friend; it only works if codes keep working long after we have been forgotten. The architecture on this page is what makes that safe to promise.

10. 10

    Operator

    QRever is operated by Sanora Technologies, from India. Questions about reliability or continuity: support@qrever.com.

See also: Security · Data Export · The Promise · What happens when a QR code expires