The service levels we aim for.
Version 1.4 · Last reviewed 11 October 2026
These are Maskbreak's operating aims, not guarantees or a report of achieved performance. The status page shows limited internal probe samples and processing measurements; it does not establish monthly uptime or compliance with a contractual SLA. Contractual commitments and service credits apply only where explicitly included in a signed agreement. Existing enterprise agreements remain unchanged, and your statutory rights are unaffected.
Operating aims
| Metric | Aim | Scope and limits |
|---|---|---|
API availability (/v1/evaluate) | 99.9% monthly | An availability aim. The public monitor checks a sample response, not authenticated visitor evaluations; it cannot verify this monthly figure. |
| Evaluation latency | <500 ms p95 | An aim for 95% of recorded evaluations to complete origin processing in under 500 ms. Excludes caller network time; the live rolling window is not a global or monthly measurement. |
| Marketing & dashboard availability | 99.5% monthly | An availability aim. The website, console and API share an application process and dependencies; an outage can affect more than one surface. |
| Support response | Aim: same business day | During UK business hours — email support@maskbreak.com. Contractual response times apply only if explicitly agreed. |
| Security disclosures | Aim: acknowledge within 2 business days | See our responsible disclosure policy for the reporting process. |
What the public measurements cover
Three kinds of check feed the status page. Every minute, probes inside the same application process that serves the status page read and write the database and check the sample API response (/v1/evaluate/sample), expected dashboard, login and signup page content, and the durable write used by authentication security checks. One failed probe marks a component degraded; an incident is opened only when two consecutive probes fail, dated from the first, and recovery needs two successful probes. Provider indicators use real server-side network, device-check, sign-in and email-send outcomes; without recent evidence they read Unknown.
Separately, GitHub Actions is scheduled every 15 minutes to check public page content, the test API contract and reported dependency failures, and to sign in with a password to a dedicated monitoring account (never a customer’s) and read it; GitHub delays the schedule, so in practice it runs every few hours and its results count for 6 hours. A Cloudflare schedule outside our hosting provider checks public pages, process health and a simulated API request every five minutes. Both can be delayed, and their results go stale (Unknown) rather than being counted as passes. None of these checks signs in to a customer’s account, confirms inbox delivery or exercises every browser SDK. Before 8 September 2026, recorded page probes checked HTTP responses only.
The status page shares the service's origin and dependencies. It may be unavailable during an outage, and a stopped process cannot record failed probes; the independent Cloudflare snapshot linked from the status page can still show its latest result. Historical percentages describe recorded samples, weighted by their sample counts where available. Gaps are not successful checks. This is not complete uptime accounting or contractual SLA reporting.
Maintenance and contractual scope
A signed SLA, if applicable, defines measurement periods, exclusions, notice requirements and remedies. This page does not add exclusions to or change an existing agreement.
| Maintenance notices | The status page contains automatic service incidents and reviewed incident and maintenance reports. No universal advance-notice period is promised here; any agreed notice period remains governed by your signed contract. |
| Customer systems | Network and integration issues can affect the experience beyond the limited measurements shown publicly. Any contractual treatment depends on the signed agreement. |
| Suspension for abuse | See the Terms of Service and any applicable signed agreement. |
| Upstream failures | Cloud and network dependencies can affect the service. This page does not automatically exclude those failures from any contractual commitment. |
Service credits
Service credits apply only if your signed agreement explicitly provides them, under its eligibility and claim terms. An enterprise plan or a signed data processing agreement does not by itself create service credits. Existing enterprise contracts remain unchanged; this page does not remove agreed remedies or affect statutory rights. To discuss contractual service levels, email support@maskbreak.com.