Enterprise Service Level Agreement
IN FORCE. See 00-README. This SLA applies only to Merchants on an Enterprise plan under a signed Order Form/MSA. Standard plans (Entry/Growth/Pro) have no uptime SLA or service credits (best-effort support only — see ToS §8). Figures are the confirmed defaults; final numbers are set in the Order Form.
Legal basis. Every provision below rests on one of three things: a measured fact about the platform (cited to file and line), a rule of law (cited to the instrument and article in the Legal Basis Register), or a commercial choice CIQRA has made where the law leaves it open. Prepared and adopted by CIQRA OÜ.
CIQRA's determination: the 99.9% monthly uptime target and service-credit remedy apply only to Enterprise Merchants under a signed Order Form/MSA; standard plans carry no uptime SLA, which this document states correctly and which matches 00-README §3. Three things were not verified in the 2026-08-09 reconciliation and should not be presented as operating controls: (i) that uptime is measured and published against a defined measurement method — an SLA whose availability figure nobody computes cannot be claimed against; (ii) that a service-credit calculation and request process exists operationally; and (iii) the priority-response targets. Observability tooling does exist (OpenTelemetry + Sentry,
Ciqra.Api.csproj:81-86), but instrumentation is not an SLA measurement obligation. Confirm the measurement method before the first Enterprise Order Form is signed — this is the one document in the set that creates a quantified, financially-remedied promise.
Provider: CIQRA OÜ, Tallinn, Estonia · In force from: 2026-08-09 · Version: 1.0 · Adopted by: CIQRA OÜ
1. Uptime commitment
1.1 Uptime target, and what attaches to it. CIQRA targets ≥ 99.9% Monthly Uptime Percentage for the core Enterprise Services (Storefront serving, checkout, and admin API). ③ Owner-confirmed commercial commitment — PA-0360. The figure is stated as an operational target: it is the availability CIQRA operates to and measures itself against, and what attaches to it is set out here rather than inferred from the number. Service credits under §3 attach for a calendar month if, and only if, CIQRA has published an uptime record for that month — the measurement defined in §1.2a, derived as §1.2b describes, published at infra/observability/uptime/, and provided to the Merchant under §1.2a's Publication row. For a calendar month with no published record, the target stands and no service-credit obligation attaches for that month; the Merchant's remedies for that month are those in the Terms of Service and Merchant Agreement. No availability figure is stated in this SLA for any month the measurement did not observe — a percentage covering a period the instrument did not watch is not a measurement, and this SLA does not print one.
1.2 Monthly Uptime Percentage = (total minutes in the month − Downtime minutes) ÷ total minutes in the month × 100, where Downtime is sustained unavailability of the core Services attributable to CIQRA.
1.2a The reference — what "measured" means here
Until 2026-08-10 this clause read "measured by CIQRA's monitoring", which named no probe, no endpoint, no interval and no way for the Merchant to see the result. 🔑 A formula without a reference is not a measurement, and §3.3's claim procedure ("CIQRA validates against its monitoring") inherited the same emptiness. The reference is now stated, as a default that an Order Form may replace:
| Default method | ③ why this value | |
|---|---|---|
| Probe | An HTTP GET to /health/ready on the Merchant's Storefront host and on the platform API host, issued from outside CIQRA's network | /health/ready already exists as the readiness endpoint; a probe run from inside the platform cannot observe the failure modes a Merchant experiences |
| Interval | Every 60 seconds per host | The smallest interval at which a credit-bearing figure is conventionally computed; a longer interval rounds short outages away, a shorter one measures noise |
| Failure | A non-2xx response, or no response within 10 seconds | A timeout is unavailability from the Merchant's side whatever the cause behind it |
| Downtime starts | At the second consecutive failed check, and ends at the first successful one | 🔴 The single most important line here: without a consecutive-failure rule one dropped packet becomes a minute of Downtime, and the figure stops meaning anything in both directions |
| Publication | The monthly figure and any Downtime intervals are provided to the Merchant on request and, in any event, with CIQRA's response to a service-credit claim under §3.3 | A figure only CIQRA can see is one the Merchant cannot check a claim against |
An Order Form may specify a different probe, interval, threshold or publication route. Where it is silent, the table above applies — which is the point of stating it: an Order Form that forgets to define measurement would otherwise leave a credit-bearing percentage with no method at all.
⏪ Superseded on 2026-08-16 by §1.2b, and kept rather than overwritten. The determination below is the record of what was true on 2026-08-10, and it is left standing because a document that silently replaces its own findings cannot be audited against the dates it made them. Read it as history; §1.2b states the current position, and where the two differ §1.2b governs.
🔴 CIQRA's determination — the method is now defined; the measurement is not running. (measured 2026-08-10) The endpoints exist (
/health,/health/ready,/health/configuration,/health/build) and observability is wired to Grafana Cloud and Sentry (see Subprocessor List rows 4 and 5), but nothing in the platform computes a monthly availability figure, and no external synthetic probe was found. So §1.1's 99.9% and the credits in §3 remain sold ahead of the instrument that would price them — PA-0360.⚠️ Two things this clause deliberately does not do. It does not claim the monitoring exists: the table above is a specification, in the future-facing sense, and is written as a default rule rather than as a description. And it does not soften §1.1 to match what is running — lowering a commitment because the instrument is missing would fix the sentence and leave the Merchant with the same nothing.
🔑 The risk is bounded today only because no Enterprise Order Form has been signed. It becomes live on the day the first one is, not on the day someone notices. An unmeasurable promise costs nothing until it is sold, and everything afterwards.
1.2b The instrument — what exists, and what it has observed
The §1.2a table above is unchanged and remains the specification. This clause records the instrument that implements it, so that §1.1's target rests on something a Merchant can point at rather than on an assurance.
| Where it lives | What it is | |
|---|---|---|
| Probe definition | infra/observability/synthetics/health-ready-probe.json | The two checks required by §1.2a's Probe row — /health/ready on the platform API host and on a Merchant Storefront host — with the 60-second interval and 10-second timeout as committed configuration, and probe locations outside CIQRA's hosting region |
| Derivation | infra/observability/synthetics/uptime-aggregate.py | Applies §1.2a's second-consecutive-failure rule and computes the Monthly Uptime Percentage from raw check results |
| Records | infra/observability/uptime/ | One record per calendar month, carrying the period, the per-host percentage, the Downtime intervals, the method and the tool that produced it |
🔴 CIQRA's determination — the instrument exists; what it has measured is a matter of record. (measured 2026-08-16) Both probe targets answer from outside CIQRA's network (
/health/ready→200, measured 2026-08-16T21:14:36Z). The second-consecutive-failure rule in §1.2a's fourth row has no equivalent setting in the monitoring provider, which reports only a per-check success flag; CIQRA therefore computes that rule itself, in the derivation tool named above, rather than adjusting the specification to match what a product happened to offer.⚠️ What this clause does not claim. It does not state an availability figure for any month, and it does not represent that a record exists for a month in which none was published. A record covering a period the probe did not observe would be a figure without a measurement behind it, which is the defect §1.2a exists to prevent. Each record states its own coverage for exactly this reason: a percentage computed from a handful of samples is arithmetically correct and evidentially worthless, and reads identically to one computed from a full month.
🔑 This is why §1.1 is written the way it is. Service credits attach for a month if, and only if, a record for that month has been published. Nothing in this SLA has to be edited for that to begin: the obligation attaches when the record appears, and does not attach for a month where none did. A commitment that depends on somebody remembering to amend a document on a particular date is a commitment that will be wrong on that date.
2. Exclusions (not counted as Downtime)
Downtime does not include unavailability caused by: (a) scheduled maintenance (see §5) or emergency maintenance; (b) factors outside CIQRA's reasonable control / force majeure; (c) third-party services outside CIQRA's control (e.g. Stripe, Cloudflare, Azure regional outage, DNS registrar, the Merchant's own integrations); (d) the Merchant's acts, misconfiguration, content, or code; (e) suspension for breach, non-payment, security or legal reasons; (f) beta/preview features; or (g) internet/network problems beyond CIQRA's edge.
3. Service credits (sole and exclusive remedy)
3.1 If CIQRA fails to meet the uptime target in a calendar month, the Merchant may claim a service credit, calculated as a percentage of that month's subscription fee:
| Monthly Uptime Percentage | Service credit |
|---|---|
| < 99.9% and ≥ 99.0% | |
| < 99.0% and ≥ 95.0% | |
| < 95.0% |
3.2 Credits are the Merchant's sole and exclusive remedy for any failure to meet the SLA. Credits are applied against future subscription fees, are non-refundable in cash, and in aggregate will not exceed the cap stated in the Order Form (the draft figure of 100% of one month's subscription fee was never decided and is not in force) for the affected month.
3.3 Claim procedure: the Merchant must request a credit in writing to support@ciqra.com within 30 days of the end of the affected month, with reasonable supporting detail (dates/times, affected Services, request logs). CIQRA validates against the measurement defined in §1.2a — not against an unnamed "our monitoring" — and provides the Merchant with the monthly figure and the Downtime intervals it relied on, so the validation can be checked rather than only announced.
4. Support response targets (Enterprise)
Priority support with target first-response times (business hours unless 24×7 is agreed in the Order Form):
| Severity | Definition | Target first response |
|---|---|---|
| S1 — Critical | Core Services down / checkout failing platform-wide for the Merchant | ≤ 4 business hours (or agreed 24×7) |
| S2 — High | Major function impaired, no reasonable workaround | ≤ 8 business hours |
| S3 — Normal | Minor/partial impact, workaround exists | ≤ 1 business day |
| S4 — Low | Question, cosmetic, feature request | ≤ 2 business days |
Response targets are time-to-first-response, not time-to-resolution. Named contacts, escalation paths and any 24×7 coverage are set in the Order Form.
5. Maintenance & communication
5.1 CIQRA aims to give ≥ 48 hours' notice for planned maintenance likely to cause Downtime, scheduled where practicable in low-traffic windows; emergency maintenance may occur with shorter or no notice. 5.2 A status page / incident communication channel is provided for Enterprise Merchants.
6. General
6.1 This SLA is part of the Enterprise Order Form/MSA and is subject to the Terms of Service and Merchant Agreement, including their liability limits (the credits here are additional to, and capped as stated in, those terms). 6.2 CIQRA may update this SLA for future terms; changes do not reduce a commitment already bought for a current term. 6.3 Data protection, security and breach handling are governed by the DPA and Retention & Breach, not this SLA. [Approach: Vercel/BigCommerce/Shopify-Plus SLA-credit structure; İkas "no standard-tier SLA" differentiator.]
End of Enterprise SLA . See: ToS §8 · Merchant Agreement.