SLA Annex — Availability commitment
Questo documento non è ancora disponibile nella tua lingua: stai leggendo la versione inglese. ClearCloud è una società francese e queste condizioni sono regolate dal diritto francese: in caso di discrepanza prevale la versione francese.
This annex forms an integral part of the OKStatus Terms of Service (article 6). In the event of a conflict between the Terms and this annex on the question of availability, this annex prevails.
Article 1 — Scope
1.1 This annex applies to the paid plans of the service: Pro, Max and Enterprise. The Free plan is provided with no availability commitment and gives no entitlement to any credit.
1.2 The availability commitment defined in article 3 applies to every paid plan. The credits defined in article 6 are reserved for the Max and Enterprise plans. For the Pro plan, the commitment in article 3 is a reinforced best-efforts obligation that gives rise to no financial compensation.
1.3 Features explicitly identified as "beta", "preview" or "experimental" in the interface or the documentation are excluded from this annex.
Article 2 — Components covered
2.1 The commitment covers three components, measured and assessed separately:
| Component | Scope |
|---|---|
| Alerting pipeline | Detection of a monitor state change and delivery of the corresponding notification to the configured channel's provider (SMTP server, Slack API, Discord webhook, etc.) |
| Check execution | Running your monitors' checks at the configured interval, from at least one of the selected regions, and recording the result |
| Dashboard and API | Authenticated access to okstatus.eu, to the public API api.okstatus.eu, and display of your public status pages |
2.2 Separate assessment means that downtime of the dashboard gives rise to no credit in respect of the alerting pipeline if the latter kept working, and vice versa. The credit due for a given month is the highest credit of the three components — credits do not accumulate across components.
2.3 Actual delivery of a notification by the channel's provider (an email landing in your mailbox, a message appearing in your Slack workspace) is beyond OKStatus's control and is not covered. The commitment stops at handover to the provider.
Article 3 — Commitment
3.1 OKStatus commits to a monthly availability of 99.9% for each of the three components defined in article 2, that is a maximum of roughly 43 minutes of downtime per 30-day month.
3.2 Monthly availability is calculated as follows, over a calendar month:
Availability = (Minutes in the month − Downtime minutes − Excluded minutes) ÷ (Minutes in the month − Excluded minutes) × 100
3.3 The result is rounded to two decimal places.
Article 4 — Definition and measurement of downtime
4.1 A component is deemed unavailable from the moment it fails three consecutive checks 60 seconds apart, and until the first successful check. The downtime period is counted from the first of the three failed checks.
4.2 The following constitute a failure: no response, a 5xx-family error response, exceeding the 30-second timeout, or a TLS certificate error.
4.3 Measurement is authoritative when it comes from the OKStatus external monitoring system, published in real time at status.okstatus.eu. That system is hosted with an infrastructure provider distinct from the one hosting the OKStatus service, and fed by probes spread across several providers.
4.4 A component is declared unavailable only if a majority of the active probes observe the failure, and that majority must include at least one probe hosted outside the infrastructure of the monitored service. An outage seen by a single probe is treated as a localised network incident and is not counted.
4.5 The availability history of the past 90 days is published openly at status.okstatus.eu, including for months in which the commitment was not met.
Article 5 — Exclusions
5.1 Periods resulting from the following are not counted as downtime:
- Planned maintenance, announced at least 48 hours in advance at status.okstatus.eu and by email to the organisation's administrators. Planned maintenance is limited to 4 hours per month and scheduled between 22:00 and 06:00 CET.
- Emergency maintenance made necessary by a critical security vulnerability, announced as soon as possible and limited to what is strictly necessary.
- Force majeure within the meaning of article 1218 of the French Civil Code, as well as major Internet transit network outages, distributed denial-of-service attacks and failures of a third-party infrastructure provider beyond OKStatus's reasonable control.
- Causes attributable to the customer: misconfigured monitors or alert channels, revocation or expiry of credentials supplied by the customer, exceeding the quotas of the subscribed plan, blocking of OKStatus probe IP addresses by the customer, use not compliant with article 4 of the Terms.
- Account suspension for non-payment or for breach of the Terms, under the conditions of articles 5.3 and 3.4 of the Terms.
- Beta features, within the meaning of article 1.3 of this annex.
5.2 The minutes corresponding to planned and emergency maintenance are removed from the denominator of the calculation in article 3.2 ("Excluded minutes"). The other exclusions are simply not counted as downtime.
Article 6 — Credits
6.1 Where the monthly availability of a component falls below the commitment in article 3.1, a customer on a Max or Enterprise plan is entitled, on claim, to a credit calculated on the amount excluding tax actually invoiced for the month concerned:
| Monthly availability observed | Downtime (30-day month) | Credit |
|---|---|---|
| ≥ 99.9% | ≤ 43 min | none |
| < 99.9% and ≥ 99.5% | 43 min – 3 h 36 | 10% |
| < 99.5% and ≥ 99.0% | 3 h 36 – 7 h 12 | 25% |
| < 99.0% and ≥ 95.0% | 7 h 12 – 36 h | 50% |
| < 95.0% | > 36 h | 100% |
6.2 For an annual subscription, the reference amount is the annual amount divided by twelve.
6.3 The credit takes the form of a credit note applied to the next billing date. It gives rise to no cash refund, neither during the contract nor on its termination.
6.4 The total credits granted in respect of a given month may not exceed 100% of the amount excluding tax invoiced for that month.
6.5 The credits provided for in this annex are the customer's sole remedy in respect of unavailability of the service, without prejudice to article 8 of the Terms. They do not accumulate with a claim for damages based on the same facts.
Article 7 — Claim procedure
7.1 The credit is not automatic: it must be claimed by the customer.
7.2 The claim is sent to sla@okstatus.eu within 30 days of the end of the month concerned. After that period, the claim is time-barred.
7.3 The claim contains:
- the identifier of the organisation concerned;
- the calendar month concerned and which of the three components in article 2 is at issue;
- the dates and times of the downtime periods relied on, in UTC, with any useful supporting evidence.
7.4 OKStatus replies within 15 working days, giving reasons for its decision and relying on the measurements published under article 4.3. If accepted, the credit note is issued with the invoice for the following period.
Article 8 — Revision
OKStatus may amend this annex under the conditions of article 10 of the Terms (30 days' notice by email for any substantial change). A downward revision of the commitment in article 3.1 or of the scale in article 6.1 gives the customer a right to terminate without penalty, exercisable until the date the change takes effect.
This document is to be reviewed by legal counsel before going into production, in particular articles 6.5 and 8 and how they interact with article 8 of the Terms (limitation of liability).