SLA / SLO & Support Policy¶
Read in your language: English · Português · Español
audit-v6 DOCS-OPS: the governance suite covers release cadence and EOL but nothing committed availability or support tiers to customers. This document defines the service objectives and support policy for the commercial SaaS control plane (
app.tlsstress.art,admin.tlsstress.art) and the on-prem product. It is a template to be finalized with the commercial terms (seeLICENSE+ the Subscription Agreement) before it is contractually binding.
1. Scope¶
- SaaS control plane — signup, billing, license issuance, usage ingestion,
dashboards hosted at
app.tlsstress.art/admin.tlsstress.art. - On-prem test bed — runs in the customer's environment; availability is the customer's responsibility. We commit to support-response objectives, not uptime, for on-prem.
- Out of scope — third-party dependencies (Stripe, AWS, Cloudflare) carry their own SLAs; a shared-fate outage there is excluded from ours.
2. Service Level Objectives (internal targets)¶
| SLO | Target | Measurement |
|---|---|---|
| Control-plane availability | 99.5% monthly | synthetic probe + edge status |
| Signup/login success rate | ≥ 99.9% (excl. user error) | auth-event success ratio |
| Billing webhook processing | ≥ 99.9% eventually-processed | stripe_webhook_events outcome (retry-aware) |
| Usage-report ingestion | ≥ 99.9% accepted (valid signed) | usage_tickets accepted ratio |
| p95 API latency (control) | < 500 ms | server timing |
These are objectives, not contractual SLAs, until §4 tiers are agreed.
3. Error budget & alerting¶
- Availability error budget: 0.5%/month (~3h39m). Burn-rate alerts at 2%/1h and 5%/6h feed the on-call.
- Health is observed by the self-hosted cloud observability stack (Prometheus +
the status page 30-day uptime); DR objectives live in
DR-RESTORE-RUNBOOK.md.
4. Support tiers (template)¶
| Tier | Audience | Channels | First-response objective | Coverage |
|---|---|---|---|---|
| Community | free / eval | email, docs | best-effort | business hours |
| Standard | Pro | email, ticketing | 1 business day | business hours |
| Enterprise | Enterprise / on-prem | ticketing + escalation | 4 business hours (Sev-1: 1h) | extended; 24/7 for Sev-1 once staffed |
Reality check (2026-07): 24/7 Sev-1 coverage is NOT yet staffed (operation is single-founder). Do not commit 24/7 in a contract until the on-call rotation exists. Sell Enterprise support as "extended business hours + best-effort escalation" until then. This aligns with the launch go/no-go.
5. Severity definitions¶
| Severity | Definition | Example |
|---|---|---|
| Sev-1 | Control plane down / billing broken / data-integrity risk | signup down, webhook loss, audit-chain break |
| Sev-2 | Major feature degraded, workaround exists | dashboard panel failing, delayed provisioning |
| Sev-3 | Minor / cosmetic | doc gap, UI polish |
6. Maintenance & change communication¶
- Planned maintenance announced ≥ 48h ahead on the status page.
- Breaking changes follow
DEPRECATION_POLICY.mdand the release cadence. - Incident comms + postmortems per the incident-response process.
7. Finalization checklist (before this is contractual)¶
- Availability % and response times agreed with the customer.
- On-call rotation staffed for the committed coverage.
- Credits/remedies defined for missed SLA.
- Referenced from the Subscription Agreement / MSA.