Status
Service Level Agreement
Availability commitment of 99.9% per calendar month, how it is measured, and the service credits payable when it is missed.
Version 1.0.0 · Effective
Draft — not yet reviewed by counsel
This agreement has not been reviewed by a qualified legal practitioner and is published for review. The measurement method in section 4 is implemented and testable regardless of that review state.
Operator details outstanding
The operating entity name, governing-law jurisdiction and contact address have not been configured for this deployment. Each appears below as a marked placeholder rather than a guess.
- Uptime target
- 99.9%
- Measured every
- 15 min
- Maximum credit
- 50%
- Maintenance notice
- 72 h
1. The commitment
[PENDING — operator to supply] commits that each community it operates will be Available for at least 99.9% of each calendar month, measured as set out in section 4. At 99.9%, permitted unavailability is approximately 43.2 minutes per 30-day month.
This commitment applies to the hosted community service: the application, its database, and the authentication required to reach them. It is measured separately for each community, because each community runs on its own isolated database and one community being unavailable does not make another unavailable.
2. What "Available" means
The community is Available when an automated check, performed from outside the service, can reach it and confirm that it is serving the correct database. A check that returns a page but is connected to the wrong tenant counts as unavailable, not available.
That last point is unusual and is stated deliberately. A service can return HTTP 200 for every request while pointed at the wrong database, in which case every query matches zero rows and the community appears empty rather than broken. The health check this agreement relies on asks whether the database agrees with the application about which community is being served, and reports a mismatch as unavailable.
3. Exclusions
Unavailability is not counted against the commitment when it results from:
- maintenance announced at least 72 hours in advance on the status page. Maintenance announced with less notice is published, but is NOT excluded;
- failure of a network, device or connection outside the operator's control, including the customer's own network and identity provider;
- suspension for non-payment, or suspension required by law;
- the customer's own configuration, including custom code, integrations, and single sign-on settings the customer controls;
- a force majeure event.
Excluded checks are removed from both sides of the calculation in section 4, so announced maintenance neither improves nor worsens the reported percentage.
4. How availability is measured
An automated check runs against every community every 15 minutes. Each check is recorded as passed or failed. Monthly Uptime Percentage is then:
100 × (counted checks − failed checks) ÷ counted checks, where counted checks are all checks in the period other than those falling inside excluded maintenance.
A failed check attributes one full 15-minute interval of unavailability. This can overstate an outage that lasted seconds and cannot understate one; the error is deliberately in the customer's favour. It also means the measurement resolution is 15 minutes: a single failed check is roughly 0.35% of a 30-day month, which is more than a third of the permitted downtime for that month.
Where 2 or more consecutive checks fail, an incident is opened and published on the status page automatically, without waiting for a person to write it. Incidents opened this way are labelled as automatically detected.
Where no check has been recorded for 60 minutes, the status page reports the community's state as unknown — it does not report it as operational. Periods with no measurements are excluded from the percentage and are shown as unmeasured rather than as 100%. If measurements are missing for a period in which the customer reasonably believes the service was unavailable, the operator will treat that period as unavailable on request.
Days are counted in UTC so that a month is the same length for every customer.
5. Service credits
If Monthly Uptime Percentage for a community falls below the commitment, the customer may claim a credit against that community's fee for that month:
| Monthly Uptime Percentage | Credit (% of that month's fee) |
|---|---|
| Below 99.9% and at or above 99% | 10% |
| Below 99% and at or above 95% | 25% |
| Below 95% | 50% |
A claim must be made within 30 days of the end of the month it relates to, in writing, to [PENDING — operator to supply], and must identify the community and the month. The operator will respond with the recorded measurements for that period.
Credits are applied against future fees, are the sole remedy under this agreement for missed availability, and do not exceed 100% of the fee for the month in question. Nothing in this section limits any right that cannot be limited by law.
6. The status page
Current state, uptime over the published windows, announced maintenance and incident history are published on the status page, readable without an account.
The state shown there is derived from the recorded checks. There is no control by which the operator can mark the service operational; a green state on that page means checks passed, and the page shows when they last ran so the reader can judge the claim rather than take it.
7. General
This agreement forms part of, and is incorporated by reference into, the Terms of Service between the customer and [PENDING — operator to supply]. It is governed by the law of [PENDING — operator to supply]. Where it conflicts with a signed order form or master agreement, that document prevails.
Changes to this agreement that reduce the commitment take effect at the start of the customer's next renewal term, not immediately. The version and effective date are shown at the top of this page and every past version is available on request.