Effective: April 29, 2026
This Service Level Agreement (“SLA”) describes the uptime, support, durability, and incident-response commitments that Axolotl Army makes for the Portal at portal.axolotlarmy.net (“the Service”). It is written in plain English first; the more formal language in each section is the binding text. If your Enterprise order form or master services agreement contains different terms, the order form governs.
This SLA applies to Enterprise subscribers of Axolotl Army during periods in which their account is in good standing (paid, not in dunning, and not suspended for breach of the Acceptable Use Policy or Terms of Service).
Customers on the Starter, Pro, and Premium plans receive best-effort service: we operate the Service to the same engineering standards as for Enterprise, including the same monitoring, alerting, and on-call rotation, and we target the same uptime number. However, those plans carry no formal uptime guarantee and no service credits. Refunds for those plans are governed exclusively by our Refund and Cancellation Policy.
/api/videos status polling for in-progress generations;/api/finance billing and subscription endpoints;/api/leads read endpoints for the Lead Finder pipeline;/api/cron heartbeat and job-dispatch endpoint;/portal/dashboard.We commit to 99.9% monthly uptime for the Service Core API. On a 30-day month that allows for approximately 43 minutes of cumulative Downtime per month before a service credit becomes due.
How uptime is measured.Uptime is measured by external monitoring (Vercel's built-in uptime monitor and our edge analytics). On request when a service-credit dispute arises we will share the relevant monitoring extracts. Internal models in our codebase that reference uptime data exist for forward compatibility and do not currently drive credit calculations.
If we miss the 99.9% target in a calendar month, Enterprise subscribers are entitled to a service credit calculated as a percentage of the monthly subscription fee paid for that month (excluding usage charges, taxes, and add-ons priced separately).
| Monthly uptime | Service credit |
|---|---|
| 99.0% to less than 99.9% | 5% of the monthly subscription fee |
| 95.0% to less than 99.0% | 15% of the monthly subscription fee |
| Less than 95.0% | 30% of the monthly subscription fee |
Service credits are subject to the following rules:
Scheduled maintenance is performed inside a recurring window of Sunday 06:00–10:00 UTC. Where we plan to use the window we announce it through an in-app banner and an email to the account owner at least 48 hours in advance. Time inside an announced scheduled-maintenance window does not count as Downtime, even if some Service Core API endpoints are unavailable during it.
Emergency maintenance is unscheduled work needed to apply security patches, rotate compromised credentials, or respond to an ongoing attack on the Service or one of its dependencies. We announce emergency maintenance as quickly as is reasonable in the circumstances — typically by in-app banner once the work is underway. Emergency maintenance does not count as Downtime.
Enterprise customers receive prioritized support with the following first-response targets. “First response” means a human acknowledging the ticket, not a fix.
| Severity | Definition | First-response target | Update cadence |
|---|---|---|---|
| P0 | Service is unavailable. | Within 1 hour, 24/7 | Hourly status updates until resolved |
| P1 | Major feature is broken with no workaround. | Within 4 business hours | Daily status updates |
| P2 | Minor issue with a viable workaround. | Within 1 business day | As progress is made |
| P3 | How-to questions and feature requests. | Within 3 business days | As progress is made |
Channels for Enterprise support:
[URGENT], [HIGH], or [NORMAL] in the subject line. [URGENT] maps to P0; [HIGH] maps to P1; everything else is triaged.“Business hours” for the purposes of P1, P2, and P3 targets are 09:00–18:00 in the customer's primary contact's timezone, Monday to Friday, excluding public holidays in that location. P0 incidents are handled 24/7.
Backups and recovery.The Service runs on Neon-managed Postgres with continuous point-in-time recovery enabled. Recovery window depends on our Neon plan and applies uniformly across customer data — there is no per-tier difference in PITR retention. Operator note: when this contract is signed for Enterprise customers, our then-current Neon plan and PITR window are disclosed in the order form.
We test restore procedures quarterly by spinning up an isolated copy of the database, verifying schema integrity and row counts, and confirming a representative sample of records. Restore tests are tracked internally and are summarized for Enterprise customers on request under NDA.
In the event of a total regional outage at our primary cloud provider, our recovery objectives are:
| Objective | Target | What it means |
|---|---|---|
| RTO (Recovery Time Objective) | 4 hours | Maximum time we expect to take to fully restore the Service after a total regional outage. |
| RPO (Recovery Point Objective) | 15 minutes | Maximum amount of data that may be lost in the worst-case recovery scenario, measured against the wall-clock state at the moment of the outage. |
These are objectives, not guarantees. A regional outage that triggers a failover counts as an Excluded Event for SLA calculations under section 2, but we still aim to meet the RTO and RPO targets above.
We notify affected customers within 72 hours of confirming unauthorized access to their data, consistent with the timeline in Article 33 of the GDPR. Notification is delivered through:
The notification will describe the nature of the incident, the categories and approximate volume of data involved, the likely consequences, and the measures we have taken or propose to take in response. Subsequent updates are issued as the investigation progresses. Reports of suspected vulnerabilities should be sent to the address listed at /legal/security.
For commitments under this SLA to apply, the customer must:
Neither party is liable for failure or delay in performance to the extent caused by circumstances beyond its reasonable control, including but not limited to: acts of God, natural disasters (earthquake, flood, fire, severe weather), pandemic, war, terrorism, civil disturbance, government action, embargo, fiber cuts, internet routing failures, regional outages of major cloud providers, large-scale DDoS attacks, and labor disputes outside the affected party's direct control. The affected party will give prompt written notice and use reasonable efforts to resume performance.
We may update this SLA from time to time. For material changes that reduce the service levels committed here — including lower uptime targets, longer maintenance windows, or smaller service credits — we will give at least 30 days' advance notice by email and an in-app banner before the change takes effect. Non-material updates (typo fixes, clarifications, formatting, new contact addresses) take effect when published. The effective date at the top of this page is updated on every change.
For SLA questions, service-credit requests, scheduled-load-test coordination, and disputes:
Send service-credit requests from the email address registered on the account. Include the impacted timeframe in UTC, the customer ID or account email, and any external monitoring evidence available so we can match it against our internal UptimeIncident records.