Status: draft. Not legal advice. The commitment below is a promise with money attached, so read §2 carefully before publishing it — the number has to be one the infrastructure can actually keep, not one that sounds impressive.
Applies to: the Studio plan only. Last updated: [DATE]
⚠️ Read this before publishing
The 99.9% figure below is a proposal, and it is not free. It allows about 43 minutes of downtime a month. On a single-server deployment — which is what
DEPLOYMENT.mdcurrently describes — one unlucky reboot, one slow migration or one provider incident spends most of that.Before committing to it, at minimum you want: a monitored
/upendpoint (built), heartbeats on the background processes (built), a rehearsed restore (done), and a deploy process that does not take the site down — which is the one that is not yet true.artisan downduring a deploy counts as downtime under §2.If you are not ready for that, offer 99.5% (about 3.6 hours a month), which is honest for a single server and still worth more to a buyer than no SLA at all. Raising a number later is easy; missing a number you published is not.
ASSUMPTION: single-region, single-application-server deployment with no automatic failover. If that changes, so should §2.
1. What this covers
This SLA applies to the availability of the TicketModules web application: the agent inbox, the customer portal, and the API that serves them.
It is measured against the /up health endpoint from an external monitoring
service — not from our own servers, because a status check that runs on the
machine which just died reports nothing useful.
It does not cover things that are not ours to promise:
| Not covered | Why |
|---|---|
| Email delivery | Depends on Mailgun and on the receiving mail server. We are not able to promise somebody else's inbox will accept a message. |
| AI drafting | Depends on Anthropic and Voyage AI. If they are down, drafting is unavailable and the desk continues working without it. |
| Payment processing | Depends on Stripe. |
| Live chat real-time delivery | Depends on the WebSocket service; a chat that cannot connect falls back to the ordinary ticket flow, which is covered. |
| Your own domain, DNS or certificate | Yours to configure. |
That table is longer than most vendors publish. It is there because an SLA that quietly implies we control Mailgun's deliverability is one we would have to argue our way out of later.
2. The commitment
We will make the service available at least 99.9% of the time in each calendar month.
ASSUMPTION — see the warning above. Change this number if the deployment cannot support it.
Monthly Uptime Percentage = (total minutes in the month − Downtime Minutes) ÷ total minutes in the month × 100.
Downtime means a period in which the health endpoint fails from two or more external monitoring locations for five consecutive minutes or more. Two locations, because a single monitoring node with a network problem is a false alarm; five minutes, because a shorter blip is not something anybody noticed or can act on.
What 99.9% permits:
| Period | Allowed downtime |
|---|---|
| Month | ~43 minutes |
| Week | ~10 minutes |
| Day | ~1.4 minutes |
3. Service credits
If we miss it, you get credit against your next invoice. You have to ask — see §5 — and this is the sole remedy for missing the commitment.
| Monthly uptime | Credit |
|---|---|
| 99.0% – 99.9% | 10% of that month's fee |
| 95.0% – 99.0% | 25% of that month's fee |
| Below 95.0% | 50% of that month's fee |
Annual plans are credited against the monthly equivalent of the annual fee, so the credit reflects the month that went wrong rather than the year.
Credits are applied to future invoices and are not paid in cash. If you cancel before a credit is applied, we will refund its cash value rather than let it lapse — a credit you cannot use is not a remedy.
Three consecutive months below 99.0% entitles you to terminate immediately, with a pro-rata refund of any unused prepaid period, whatever the Terms otherwise say about notice. If we are that unreliable, being locked in is the real harm and a 10% credit does not address it.
4. What does not count as downtime
- Planned maintenance, announced at least 48 hours beforehand and limited to 4 hours per month, carried out between 01:00 and 05:00 UTC.
- Emergency maintenance to address a security issue — announced as soon as we reasonably can, which is sometimes afterwards.
- Anything caused by your own configuration, your own domain or DNS, or a change you made.
- Anything caused by you exceeding documented rate limits, or by traffic that is an attack rather than use.
- The excluded dependencies in §1.
- Force majeure, and outages at our hosting provider that they classify as covered by their own SLA — where we recover from their provider, we pass the corresponding credit on to you rather than keeping it.
5. Claiming
Email [CONTACT EMAIL] within 30 days of the end of the affected month, with the dates and times you observed and, if you have it, your own monitoring data.
We will respond within 10 working days. Where our own monitoring already shows the shortfall we will apply the credit without argument; we will not require you to prove something we can already see. If our records disagree with yours, ours are the reference, and we will show you what they say rather than simply asserting them.
6. Availability of this SLA
This SLA is part of the Studio plan. It does not apply to Free, Author, trial workspaces, or to any period in which your account is suspended for non-payment or a breach of the Terms.
Free and Author plans are provided on a best-effort basis with the same infrastructure and the same public status page — the difference is that no money is attached to the number.
7. Changes
We may change this SLA on 30 days' notice. If a change reduces the commitment, you may cancel before it takes effect and receive a pro-rata refund of the unused period.
[LEGAL ENTITY NAME], [REGISTERED ADDRESS] — [CONTACT EMAIL]