Service Level Agreement
This SLA defines the uptime and support response commitments SideQuest makes to paid customers. It applies in addition to (and is incorporated into) our Terms of Service and any signed Master Service Agreement.
The connector itself runs on the customer's computer, so most "downtime" you might experience is actually about whether our control plane (the small API service that validates licenses) is reachable. The connector caches license state locally for 7 days, so brief control-plane outages do not stop POs from being processed.
1. Control plane uptime
We commit to the following monthly uptime for the SideQuest control plane API:
| Tier | Monthly uptime commitment |
|---|---|
| Free | Best-effort. No SLA. |
| Starter | 99.0% |
| Growth | 99.5% |
| Scale | 99.5% |
| Unlimited | 99.9% |
"Uptime" is measured as the percentage of total minutes in the calendar month during which the /healthz endpoint returns HTTP 200 within 5 seconds. Scheduled maintenance windows announced at least 48 hours in advance are excluded from the calculation.
A 99.0% target allows for about 7.2 hours of downtime per month. 99.5% allows for about 3.6 hours. 99.9% allows for about 43 minutes.
Today we run on a single-region Fly.io machine, which historically achieves 99.5% to 99.9% naturally. The Scale and Unlimited tiers' targets reflect our willingness to add multi-region redundancy if the customer base needs it.
2. What happens when the control plane is down
Because the connector caches license state locally for 7 days, a control plane outage typically does NOT prevent customers from processing POs. Behavior during an outage:
| Outage duration | What the customer experiences |
|---|---|
| Less than 7 days | Connector keeps processing POs against cached license state. Usage events buffer locally and upload when the control plane returns. |
| 7 days or more | Connector refuses to validate license; processing pauses until the control plane returns or until Paul ships an emergency override. |
In other words, you do not lose a day of work just because our server is down.
3. Support response commitments
These define how quickly we respond to support emails after the customer's initial contact, not how quickly the issue is fully resolved.
| Tier | First-response target | Hours |
|---|---|---|
| Free | Best-effort, typically 1-3 business days | Business hours |
| Starter | Within 24 hours | Business hours (Mon-Fri, 9am-5pm ET) |
| Growth | Within 8 business hours | Business hours |
| Scale | Within 2 business hours | Business hours |
| Unlimited | Within 1 hour, including evenings and weekends | 24/7 |
"Business hours" means Monday through Friday, 9 AM to 5 PM US Eastern Time, excluding US federal holidays.
For Scale and Unlimited customers, an emergency contact phone number is provided at contract signing.
4. Service credits
If we miss the uptime commitment for a paid tier in a given calendar month, the customer is entitled to a service credit:
| Actual monthly uptime | Service credit |
|---|---|
| At or above the committed target | None |
| Below target, but above 95.0% | 10% of monthly fee |
| Below 95.0%, but above 90.0% | 25% of monthly fee |
| Below 90.0% | 50% of monthly fee |
Service credits apply to the customer's next monthly invoice. They are the customer's sole and exclusive remedy for missed uptime targets.
To claim a credit, the customer must email [email protected] within 30 days of the affected month, referencing the relevant outage and timing. We verify against our internal uptime logs and apply credits within 30 days.
5. Exclusions
The following are not counted against our uptime commitments:
- Scheduled maintenance windows announced at least 48 hours in advance via email to active customers
- Outages caused by force majeure events (natural disasters, war, government action, internet backbone failures, etc.)
- Outages caused by the customer's own actions (e.g., a misconfigured firewall blocking our endpoints)
- Outages of third-party services we depend on (Fly.io, Neon, Stripe, Google, Intuit), where the third-party service itself is the root cause. We will pursue credits from those vendors and pass them through to affected customers where applicable.
- Beta or experimental features explicitly labeled as such
6. Maintenance windows
We try to do all infrastructure changes (deploys, migrations, config changes) during low-traffic windows: typically late evenings or weekends US time. Most deploys cause a 5-to-15-second pause in the control plane, which the connector retries through automatically.
We do not have regularly scheduled maintenance windows today. If we add them in the future, they will be communicated at least 30 days in advance.
7. Reporting and transparency
Customers can check current control plane health at any time at:
- https://sidequest-control-plane.fly.dev/healthz — returns
{"status":"ok"}when the API is responsive - https://sidequest-control-plane.fly.dev/ — public status page with live customer + usage counts
We commit to publishing a post-mortem within 30 days of any incident that triggers service credits or affects more than 25% of paid customers.
8. Changes to this SLA
We may update this SLA. Material changes will be communicated to all active paid customers via email at least 30 days before taking effect. Improvements (more uptime, faster response targets) take effect immediately.
Contact
To report an incident or claim a service credit: [email protected], subject line starting with [SLA].
For Scale and Unlimited customers, the emergency contact phone number provided at contract signing applies.