A 99.9% monthly uptime target for every scan

This Service Level Agreement ("SLA") sets out the availability we commit to for MostlyQR code scans, how we measure it, and the service credits you receive if we miss it. It applies to business customers on a MostlyQR Enterprise contract, and to any other customer whose order form says that it includes this SLA. On every other plan, Business included, the same target is our published objective and the status page is open to you, but no service credits are due. This SLA takes effect on 1 November 2026.

1. What is covered

The covered service is MostlyQR code scans: a request to a MostlyQR short link being answered by our redirect service — with a redirect to the code's current destination, or with the page our redirect service shows for that code before the redirect (a passcode prompt, or a request to share the scanner's location for a location-based rule). This is the component called "QR code scans" on our status page. Short links on a custom domain that MostlyQR serves for you are answered by the same redirect service and are covered in the same way.

Not covered by the service credits below: the website, the dashboard, the builder, the REST API, scan analytics, and hosted pages — the digital business cards, link pages, landing pages and forms published at mostlyqr.com/p/…, including when a code opens one. We monitor all of them on the same status page and work to the same standard, but scan redirects are what your printed codes depend on, so they are what this SLA guarantees.

2. Our commitment

We will make the covered service available at least 99.9% of the time in each calendar month (UTC). That allows about 43 minutes of downtime in a 30-day month.

3. How availability is measured

• What we probe. Our status service (status.mostlytiny.io) sends a real scan to a dedicated canary code on mqr.sh from two independent network regions, and checks that it is answered with the expected redirect. Custom domains are served by the same redirect service but are not probed separately, so the measurement is the one taken on mqr.sh.
• How often. Each region checks every 60 seconds. While an outage is confirmed, checks back off and run less often (at most every 5 minutes) until the service recovers.
• When downtime starts and ends. A failure counts only once it is confirmed: three consecutive failed checks, seen in both regions. Downtime runs from that confirmation — the minutes of the three checks that confirmed it are not counted — until the service is confirmed working again (two consecutive successful checks). A failure seen from one region only is investigated but not counted, because it usually means a problem with that region's network rather than with MostlyQR.
• How a minute is weighted. A major outage counts as a full minute of downtime, a partial outage (some scans failing) as 0.3 of a minute, and degraded performance (slow but working) as no downtime. Because we probe a single canary code, our monitoring itself records scans as either working or down; a partial outage is recorded only when we declare one in a published incident on the status page.
• Incidents and corrections. What we publish on the status page feeds the measurement too. A published incident that declares the "QR code scans" component down counts as downtime even when our probe did not see it. Our operators can also correct the record when the probe is wrong — for example a false alarm caused by the monitoring itself — either for a past period or by setting the component's state directly while an event is under way. A correction takes precedence over both the probe and any published incident for the minutes it covers, so it can reduce counted downtime. Every correction is logged with who made it, when, the period and state it covers, and a written reason, and that log is kept for at least 24 months. If you make a claim, we will show you every correction that affects the period you claim for, with its reason; if we cannot show a reason for a correction that reduced your downtime, we will disregard that correction for your claim. Raw probe checks are kept for 14 days; the per-minute record built from them, and the correction log, are kept for the whole claim period.
• Monthly Uptime Percentage = 100% × (1 − downtime minutes ÷ eligible minutes). Eligible minutes are all the minutes in the month, minus any minutes in an excluded event (section 5) and any minutes in which our own monitoring could not take a measurement. Unmeasured minutes are never counted as available.
• The same measurement drives the public uptime history on the status page (https://status.mostlytiny.io/mostlyqr), which publishes a 90-day uptime figure for each component once 30 days have passed since its first day of measurements, so you can check our arithmetic. If your own monitoring disagrees with ours, send us your data with your claim and we will review both.

4. Service credits

If the Monthly Uptime Percentage falls below the commitment, you are entitled to a credit against the MostlyQR fees for the affected month (one twelfth of the annual fee on an annual plan):

• How to claim. Ask through MostlyQR support (mostlyqr.com/support) within 30 days after the end of the affected month. Tell us the account and the dates and times you were affected.
• How it is paid. We apply the credit to your next invoice. Credits are capped at 50% of the fees for the affected month and cannot be transferred. They have no cash value, except that if your contract ends, an unused credit for the final month is refunded.
• Service credits are your sole and exclusive remedy for our failure to meet this SLA, except where the law does not allow our liability to be limited in that way.

5. What is excluded

Downtime does not count against the commitment when it is caused by:

• your destination being down, slow or blocking visitors — MostlyQR still redirects correctly to it;
• your own DNS for a custom domain being changed, expired or misconfigured, or a certificate we cannot renew because the domain no longer points at MostlyQR;
• a code, page or account that we suspended or disabled under our Terms of Service or Acceptable Use Policy, or because the law requires it;
• your breach of the Terms, or traffic you send that exceeds your plan's documented limits;
• features labelled beta, preview or experimental;
• events beyond our reasonable control (force majeure), such as a failure of the public internet outside our and our providers' networks. A failure of our own hosting or network providers (Google Cloud, Cloudflare) is not excluded.

We do not schedule maintenance that takes scan redirects offline: under our maintenance policy the scan redirect never closes for maintenance, so planned maintenance windows elsewhere in the product never count as scan downtime.

6. Status and incident communication

• Live status, incidents, maintenance windows and uptime history: https://status.mostlytiny.io/mostlyqr
• You can subscribe there to email notifications for MostlyQR, or for the "QR code scans" component only.
• During an incident we post updates at least every 30 minutes (every 15 minutes for a critical incident) until it is resolved.

7. Changes

We may update this SLA. We will not reduce the commitment or the credits during a term you have already paid for, and we give at least 30 days' notice of any change that is less favourable to you.

Approved — takes effect from 2026-11-01.

Service Level Agreement. If you are a business customer on a plan that includes our Service Level Agreement, published at https://mostlyqr.com/sla, the availability commitment, measurement method, exclusions and service credits in it apply to you in addition to this section. The service credits it describes are your sole and exclusive remedy for our failure to meet that commitment, except where the law does not allow our liability to be limited in that way.