Service Level Agreement (SLA)
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.
1. Scope
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.
2. Definitions
- “Service”
- The Axolotl Army Portal application served at portal.axolotlarmy.net, including its API, dashboard, and background workers. The Service expressly excludes:
- Third-party services we depend on, including Stripe, the Google APIs (Workspace / Maps / Calendar / Gmail), Microsoft Graph, Anthropic, ElevenLabs, OpenAI, Kie.ai, Runway, Deepgram, Cloudflare, Resend, Blotato, Upstash, Sentry, and any other sub-processor listed at /legal/subprocessors;
- The customer's own network, devices, browser configuration, or in-house integrations;
- Scheduled maintenance windows announced under section 5;
- Emergency maintenance performed for security reasons (zero-day patching, credential rotation following a vendor incident).
- “Uptime”
- The percentage of minutes in a calendar month during which the Service Core API responds with HTTP 2xx or 3xx status codes for its healthy endpoints, measured from our internal uptime monitor.
- “Downtime”
- A sustained period of five (5) minutes or more during which Service Core API endpoints return HTTP 5xx errors or time out, excluding events that are Excluded under section 2 (4) below. Brief blips under five minutes are not Downtime under this SLA but are still tracked for our internal reliability metrics.
- “Service Core API”
- The endpoints whose availability defines the Service for the purposes of this SLA:
- Authentication endpoints (sign-in, sign-up, session refresh);
/api/videosstatus polling for in-progress generations;/api/financebilling and subscription endpoints;/api/leadsread endpoints for the Lead Finder pipeline;/api/cronheartbeat and job-dispatch endpoint;- The dashboard render at
/portal/dashboard.
- “Excluded Event”
- Any of the following:
- Scheduled maintenance announced at least 48 hours in advance;
- Emergency maintenance reasonably necessary to apply security patches, rotate compromised credentials, or respond to an ongoing attack;
- Force majeure events, including: cloud-provider regional outages, internet routing failures (BGP, transit-provider outages), large-scale DDoS attacks, fiber cuts, natural disasters, war, terrorism, government action, and labor action;
- Outages or degradations of any third-party service the Service depends on, where that third party is the root cause and the Service itself is responding correctly;
- Customer-caused issues, including but not limited to rate-limit overages, abuse triggering AUP enforcement, custom-integration failures, or load tests that have not been coordinated with us under section 10.
3. Uptime commitment
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.
4. Service credits (Enterprise only)
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:
- Credits are applied to the next invoice issued after the credit is approved. Credits do not extend the subscription term and are not redeemable for cash.
- The maximum cumulative credit in any single calendar month is capped at 30%of that month's subscription fee.
- Service credits are the customer's sole and exclusive remedy for Downtime under this SLA, except where applicable law requires otherwise.
- Customers must request the credit within 30 days after the end of the affected month by emailing legal@axolotlarmy.net with the impacted timeframe (start and end timestamps in UTC) and any monitoring evidence available. Requests outside the 30-day window are not eligible.
- A customer in active dunning (FAILED, LOCKED, or SUSPENDED status, per section 6 of the Refund and Cancellation Policy) does not accrue service credits for the affected month.
5. Maintenance windows
5.1 Scheduled maintenance
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.
5.2 Emergency maintenance
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.
6. Support response targets (Enterprise)
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:
- Email: legal@axolotlarmy.net with
[URGENT],[HIGH], or[NORMAL]in the subject line.[URGENT]maps to P0;[HIGH]maps to P1; everything else is triaged. - For Enterprise customers we will set up a shared communication channel (Slack Connect or similar) on request during onboarding. This is provisioned manually rather than via product-side automation.
“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.
7. Data durability and backup
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.
8. Disaster recovery
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.
9. Security incidents
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:
- An in-portal banner visible to the account owner; and
- An email to the account owner's registered contact address.
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.
10. Customer obligations
For commitments under this SLA to apply, the customer must:
- Maintain a valid contact email on the account so that maintenance windows, security notifications, and incident updates can reach you;
- Pay invoices on time. Accounts in dunning (FAILED, LOCKED, or SUSPENDED status under section 6 of the Refund Policy) do not accrue service credits for the affected month;
- Not artificially induce Downtime — load tests, penetration tests, and synthetic high-throughput workloads must be coordinated with us at least 5 business days in advance by email to legal@axolotlarmy.net;
- Operate within the Acceptable Use Policy at /legal/aup.
11. Force majeure
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.
12. Changes to this SLA
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.
13. How to contact us
For SLA questions, service-credit requests, scheduled-load-test coordination, and disputes:
- Email: legal@axolotlarmy.net
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.