This Service Level Agreement (“SLA”) describes the uptime commitments, definitions, and credit structures for Mataki Labs LLC (“AuditStore”) cloud services. This SLA applies to customers on the Launch, Scale, and Enterprise plans. The Dev plan is offered on a best-effort basis and is not covered by this SLA.
If you have executed a Master Services Agreement (MSA) with AuditStore, the SLA terms in your Service Order supersede this published SLA to the extent of any conflict.
1. Definitions
“Monthly Uptime Percentage” means the total minutes in a calendar month minus the minutes of Downtime, divided by the total minutes in the calendar month, expressed as a percentage.
“Downtime” means any period during which a Service is materially unavailable for reasons attributable to AuditStore’s infrastructure, as measured by AuditStore’s external monitoring systems. Downtime does not include:
- Scheduled maintenance communicated at least seventy-two (72) hours in advance via email or the AuditStore status page.
- Force majeure events including natural disasters, war, pandemics, government actions, or Internet backbone failures beyond AuditStore’s control.
- Customer-caused unavailability including issues arising from Customer’s equipment, software, network, SDK misconfiguration, or actions/inactions of Customer’s users.
- Third-party infrastructure outages affecting upstream cloud providers, DNS providers, or other services not operated by AuditStore, except to the extent AuditStore’s architecture could have reasonably mitigated the impact.
- Beta, preview, or experimental features not designated as generally available.
“Service Credit” means a percentage of the monthly Fees for the affected Service, credited to Customer’s account as described in Section 3.
2. Uptime Targets by Service and Plan
By Plan Tier
| Plan | Uptime Target |
|---|---|
| Dev | Best effort (no SLA) |
| Launch | 99.9% |
| Scale | 99.95% |
| Enterprise | 99.99% (custom SLA available) |
By Service
| Service | Uptime Target | Notes |
|---|---|---|
Event Ingestion API (POST /events, POST /events/raw) | Per plan tier | Core write path. Highest priority — audit events must always be accepted. |
Query API (GET /events, GET /events/{id}) | Per plan tier | Read path for event retrieval and filtering. |
Integrity API (GET /events/{id}/proof, GET /events/chain) | Per plan tier | Merkle proof generation and chain verification endpoints. |
Export API (POST /exports) | Per plan tier | Async export initiation. Export delivery depends on destination availability. |
Ledger Management API (/ledgers) | Per plan tier | Ledger creation, configuration, and legal hold management. |
| Dashboard (app.auditstore.dev) | 99.9% | Web console for account, ledger, and API key management. |
| Documentation (docs.auditstore.dev) | 99.95% | Static content served via CDN. Higher target reflects simpler infrastructure. |
Note: The Event Ingestion API is architecturally prioritized. In degraded conditions, AuditStore may temporarily reduce availability of the Query API, Export API, or Dashboard to maintain ingestion availability. Audit events should always be accepted.
3. Service Credits
If the Monthly Uptime Percentage for a Service falls below the applicable Uptime Target in a given calendar month, Customer is entitled to a Service Credit calculated as follows:
| Monthly Uptime Percentage | Service Credit |
|---|---|
| 99.0% to < Uptime Target | 10% of monthly Fees for the affected Service |
| 95.0% to < 99.0% | 25% of monthly Fees for the affected Service |
| Below 95.0% | 50% of monthly Fees for the affected Service |
Credit Terms
- Service Credits must be requested in writing to support@auditstore.dev within thirty (30) days of the end of the month in which the Downtime occurred.
- Requests must include the dates and times of the Downtime and a description of the impact.
- Service Credits are applied as a credit against the next invoice. Credits are not redeemable for cash and may not be transferred.
- Service Credits may not exceed 50% of the monthly Fees for the affected Service in any calendar month.
- Service Credits are Customer’s sole and exclusive remedy for failure to meet the Uptime Target.
4. Incident Reporting
Upon Customer’s reasonable request, AuditStore will provide a written incident report for any Downtime event exceeding fifteen (15) consecutive minutes, including:
- Root cause analysis
- Duration and timeline of the incident
- Affected services, endpoints, and regions
- Impact on event ingestion and hash-chain integrity
- Remediation steps taken
- Measures implemented to prevent recurrence
Incident reports are typically provided within five (5) business days of the request and are subject to confidentiality obligations.
Integrity Impact Disclosure
If any Downtime event has the potential to affect hash-chain integrity or event ordering, AuditStore will proactively disclose this in the incident report, including the affected Ledgers, sequence ranges, and verification steps Customers should take.
5. Scheduled Maintenance
AuditStore performs routine maintenance to ensure the reliability and security of the Services. Scheduled maintenance is:
- Communicated at least seventy-two (72) hours in advance via email to account administrators and via the status page.
- Conducted during low-traffic windows when possible (typically weekends, 02:00–06:00 UTC).
- Designed to minimize or eliminate user-visible impact. Most maintenance is performed with zero downtime using rolling deployments.
Emergency maintenance (required to address critical security vulnerabilities or imminent service failures) may be performed with shorter notice. AuditStore will provide as much advance notice as is reasonably practicable under the circumstances.
SDK buffering during maintenance: The AuditStore SDKs buffer events in-process and retry on transient failures. Brief maintenance windows (under 5 minutes) are typically transparent to applications using the SDK with default configuration.
6. Data Durability
In addition to availability commitments, AuditStore commits to the following data durability guarantees:
- Zero event loss: Once the API returns a successful response (HTTP 200/201) for an event ingestion request, that event is durably stored. Events acknowledged by the API will not be lost due to infrastructure failures.
- Hash-chain consistency: The hash chain within each Ledger is maintained continuously. AuditStore monitors for chain inconsistencies and will notify affected Customers within 24 hours of detection.
- Integrity proof availability: Merkle proofs remain available and valid for all events within the active retention window of a Ledger.
7. Exclusions
This SLA does not apply to:
- The Dev plan (offered on a best-effort basis).
- Beta, preview, or experimental features.
- Services suspended pursuant to the Terms of Service, Acceptable Use Policy, or MSA.
- Downtime caused by Customer’s actions or inactions, including SDK misconfiguration, excessive rate limit violations, or malformed API requests.
- Conditions described in the Downtime exclusions in Section 1.
8. Changes
AuditStore may update this SLA from time to time. Changes will not reduce the Uptime Target or Service Credit percentages during a Customer’s current subscription period. Changes take effect for new subscriptions and upon renewal of existing subscriptions.
9. Contact
Questions about this SLA or Service Credit requests should be directed to support@auditstore.dev.