Service Level Agreement
What we commit to on availability and support, by tier.
Draft — not yet reviewed by counsel. This document is published for internal review and customer feedback. It does not yet bind Eduworks or any customer, and it must not be relied on in a contract or a security review until legal review is complete.
Questions or corrections: legal@eduworks.com.
Last updated September 2026.
Read this before relying on CADRE for something time-critical. Self-service subscriptions are offered on a best-effort basis with no guaranteed uptime percentage and no service credits. A committed availability target is available on sales-supported and enterprise agreements. We would rather tell you that plainly than publish a number we are not yet measuring well enough to stand behind.
Tiers
| Tier | Availability commitment | Support response target | Remedy |
|---|---|---|---|
| Self-service | Best-effort. No committed percentage. | Email, best-effort, no committed response time. | None. |
| Sales-supported | Committed target, set in your order form. | Set in your order form. | Service credits where agreed. |
| Enterprise / Government | Negotiated, including dedicated and on-premises options. | Negotiated, including escalation contacts. | As contracted. |
[Committed percentages, response times and credit schedules for the sales-supported tier to be set by Legal and Ops before this tier is sold.]
What we do to keep instances up
These apply to every tier, including self-service:
- Each instance is health-checked continuously from outside the cluster through its public hostname, so the check covers DNS, TLS, the ingress and the application — the same path your users take. A restricted instance is still checked, so switching on a network restriction does not remove you from monitoring.
- Failures raise an alert to our team automatically. We alert on a confirmed failure rather than a single missed check, so that a routine restart does not generate noise that trains people to ignore real outages.
- Instances are reconciled continuously and restored automatically where the platform can do it without human involvement.
- Storage grows automatically ahead of demand, rather than waiting for an instance to run out of room.
- Maintenance that requires a restart is deferred to a weekly window rather than applied when discovered, and is rate-limited so that not every instance is affected at once.
What does not count as downtime
For tiers with a committed target, these periods are excluded when availability is calculated:
- Backups and restores that you start. These deliberately take the instance offline for their duration; you choose when they run.
- Announced maintenance windows.
- An outage caused by your own configuration — for example a network restriction that excludes your users, sign-in settings pointing at an identity provider that is not working, or a custom domain whose DNS record has changed.
- An outage at your identity provider, which prevents sign-in without the instance itself being down.
- Suspension for non-payment or for breach of the Acceptable Use Policy.
- Features labelled beta or preview.
- Events outside our reasonable control, including failure of the underlying cloud platform or of a subprocessor listed on the Trust Center.
Notification and status
We notify the account owner about events that affect their instance — it becoming reachable for the first time, backups and restores, configuration and access changes, and shutdown. A public status page and published historical uptime are in progress; until then, ask us and we will tell you what we know.
Claiming a credit
Where your agreement provides service credits, submit a claim to support@eduworks.com within 30 days of the incident, with the dates, times and effect. Credits are applied against future fees and are the sole remedy for failure to meet a committed availability target.