Numbers we'll defend.
This is the default SLA that applies to every paying SousOps customer. Enterprise contracts can negotiate tighter numbers; none can negotiate looser ones than this page promises. Trade-offs are stated plainly — where the cap is the monthly subscription fee, the doc says so.
Uptime commitment
99.5% monthly uptimefor the production dashboard and APIs. Measured as100 × (1 - downtime_minutes / total_minutes)over a calendar month. Live status at /status.
What counts as downtime:HTTP error responses (5xx) on the production domain or inability to authenticate, sustained for ≥5 consecutive minutes during a billing period. Single-request timeouts that recover do not count.
What does not count:
- Scheduled maintenance announced ≥48 hours in advance.
- Customer-side configuration errors (e.g., disconnected OAuth integrations).
- Sub-processor outages (Supabase, Vercel) provided we publicly post and follow the incident-response playbook.
- Force majeure: regional internet outages, war, government action.
Service credits
If we miss the 99.5% target in a month, customers receive a service credit on the following invoice:
| Monthly uptime | Credit (% of monthly fee) |
|---|---|
| 99.0% – 99.49% | 10% |
| 95.0% – 98.99% | 25% |
| Below 95.0% | 50% |
Credit cap.Total credits in any month are capped at the customer's monthly subscription fee for that month. SousOps's aggregate liability under this SLA is the credit. We don't offer consequential damages, lost-revenue indemnification, or third-party claims — that's standard SaaS, but we're saying it plainly.
How to claim.Email support@palisirestaurantgroup.com within 30 days of the affected month. Credit applied on the next invoice cycle, no other paperwork required.
Support response times
Initial acknowledgement targets, measured during business hours (M–F, 8am–6pm ET):
| Severity | Example | Acknowledge by |
|---|---|---|
| Critical | Dashboard down for all users in your org; data exposure suspected | 1 hour |
| High | Single feature broken; financial data discrepancy | 4 hours |
| Standard | Question, configuration help, feature request | 1 business day |
Critical-severity issues outside business hours: acknowledge within 4 hours, then resume normal cadence at next business-hour window. Critical incidents trigger the playbook inDR_RUNBOOK.md regardless of hour.
Incident notification
Customer-impacting incidents:posted to /status within 30 minutes of confirmation, regardless of severity.
Security incidents:acknowledged to affected customers within 24 hours per SECURITY.md. Notification under GDPR / similar regimes within 72 hours of detection per DPA §9.
Postmortems:published within 14 days for any incident with ≥1-minute customer impact. Posted at /status under recent incidents.
Scheduled maintenance
We don't have weekly maintenance windows. Most deployments ship through Vercel's zero-downtime promotion path with no customer-visible window. When a deployment requires a longer schema change or sub-processor switch:
- ≥48 hours advance notice via email + status page banner.
- Scheduled between 2am and 5am ET on a Sunday morning.
- ≤30 minute target window. Real duration logged on status page after the fact.
Data retention and portability
Customer data is retained for the active subscription period plus a 30-day grace window after termination. Self-serve export available at any time via /api/me/export — single JSON file with every row owned by the org across the 16 tables documented at /dashboard/settings/data-export.
After the 30-day grace window, customer data is hard-deleted via FK ON DELETE CASCADE within an additional 30 days unless a legal hold applies. The deletion is audit-logged for posterity.
How to reach us
- Support: support@palisirestaurantgroup.com
- Security: security@palisirestaurantgroup.com
- Privacy / GDPR: security@palisirestaurantgroup.com
- Status: /status
Changes to this SLA
Material changes (reductions in commitments, removals of categories, or changes to credit calculations) require 60 days advance noticeto the customer's primary billing email and a banner on the dashboard during that window. Improvements (tighter SLAs, broader scope) take effect on publication.
Change history is captured in git: see this file's log in the public repository linked from sousops.com.