Service Level Agreement

This Service Level Agreement ("SLA") describes Brimble's availability commitment for eligible paid services, how availability is measured, and the service credits available if Brimble does not meet that commitment.

Effective date: 12 October 2026

1. Overview

This SLA supplements the Brimble Terms of Service. Capitalized terms not defined here have the meanings given in the Terms of Service.

2. Eligibility and Scope

This SLA applies to customers with an active, paid Hacker, Developer, or Team subscription, and only to the Brimble-managed services listed as covered below.

The Free plan, preview and beta features, trial services, and customer-managed infrastructure are excluded unless a separate written agreement states otherwise.

A service not listed as covered is not subject to a contractual uptime commitment under this SLA.

Platform availability and application availability are different things. Brimble is responsible for the infrastructure it manages: the platform edge, the hosts and orchestration that run workloads, and the managed database instances. Brimble is not responsible for whether a customer's own code works. An application that is unreachable because a Brimble-managed host, network, or orchestration component failed counts as Eligible Downtime, including for single-instance applications. An application that is unreachable because of its own code, configuration, or dependencies does not.

3. Availability Commitment

For each covered service, Brimble commits to a Monthly Uptime Percentage of at least 99.9%, subject to the exclusions in Section 5.

• Measurement period: One calendar month in UTC.
• Covered Service: A Brimble-managed service listed as covered in Section 2.
• Eligible Downtime: Time during which a Covered Service fails its availability checks due to a Brimble-controlled failure, excluding Excluded Downtime.
• Excluded Downtime: Time attributable to the causes in Section 5. Excluded minutes are removed from the measurement period and do not count as Eligible Downtime.

Monthly Uptime Percentage = ((Total minutes in month − Excluded minutes − Eligible Downtime minutes) / (Total minutes in month − Excluded minutes)) × 100

If the denominator is zero, no Monthly Uptime Percentage or credit is calculated for that period.

Availability is measured using Brimble's monitoring and incident records, supported by relevant customer evidence.

4. Regional and Deployment Boundaries

Availability is assessed per Covered Service and, where relevant, per deployment region. An incident affecting one region is not automatically counted as downtime for another region.

Single-instance workloads have no redundancy, so a failure of the host running them interrupts the service until it is recovered on another host. That interruption counts as Eligible Downtime when the failure is in Brimble-managed infrastructure. Multiple instances (configured through autoscaling), backups, and high-availability database configurations reduce interruptions but require explicit configuration. Brimble is responsible only for the managed components and eligible configurations listed in Section 2.

5. Exclusions

The following do not count as Eligible Downtime, to the extent they cause the interruption:

1. Customer code, configuration errors, application faults, unsupported workloads, or resource exhaustion resulting from the customer's configuration or usage.
2. Customer-initiated deployments, restarts, scaling events, deletion, or administrative actions.
3. Failures of customer-managed systems, third-party integrations, customer DNS configurations, or external networks outside Brimble's reasonable control.
4. Scheduled maintenance announced at least 48 hours in advance on status.brimble.io. Unannounced emergency maintenance is not excluded and counts as Eligible Downtime.
5. Suspensions or restrictions permitted under the Terms of Service, including for non-payment or security abuse.
6. Force majeure events, subject to applicable law and the Terms of Service.
7. Services, features, or configurations not listed as covered in Section 2.

An exclusion does not apply merely because a third-party provider is involved if Brimble has expressly assumed responsibility for that dependency for a Covered Service.

6. Service Credits

If a Covered Service falls below a 99.9% Monthly Uptime Percentage, an eligible customer may request a service credit according to the following schedule:

Eligible Monthly Service Charges means the amount actually paid or payable for the affected Covered Service during the affected month, excluding taxes, domain registration, third-party add-ons, and other unaffected products. Where a service is billed by usage, Brimble uses the charges attributable to the affected service itself (the compute, storage, and bandwidth billed for that specific application or database in that month), not the customer's entire subscription, other projects, or wallet balance.

Credits are applied to future Brimble invoices, are not cash refunds, and are capped at 50% of the Eligible Monthly Service Charges for the affected Covered Service for that month. Credits cannot exceed the amount charged for that service.

Service credits are the sole and exclusive remedy for any failure by Brimble to meet this SLA.

7. Requesting a Credit

Customers must submit credit requests through Brimble Support within 30 calendar days after the end of the affected month. Requests should include the service identifier, region, approximate incident window, and any supporting logs or request IDs.

Brimble reviews each request as soon as it is received, checks it against its monitoring and incident records, and keeps the customer updated until a determination is made. Approved credits are applied to a subsequent invoice. If a customer disagrees with a determination, they can respond to the same request and Brimble will continue to work through it with them.

8. Incident Communications and Maintenance

Brimble monitors platform infrastructure and works to restore affected services promptly. Incident notices and maintenance updates are published on status.brimble.io. This SLA does not promise a specific support response or restoration time unless expressly stated in a separate written agreement.

9. Support Escalation Matrix

Customers should raise every issue with Brimble Support first. If an issue affecting a Covered Service is not progressing, the customer may escalate it to the next level. Include the original support request reference, the service identifier, and the region when escalating.

10. Enterprise Arrangements

A customer and Brimble may sign an Enterprise SLA Addendum that modifies availability targets, credit schedules, service scope, escalation processes, or other terms. If a signed Enterprise SLA Addendum directly conflicts with this SLA, the Addendum controls for that customer's covered services. Otherwise, this SLA continues to apply.

11. Updates and Governing Terms

Brimble may update this SLA in accordance with the notice and amendment provisions of the applicable customer agreement. Updates are published at brimble.io/legal/sla. The governing law and dispute resolution provisions of the applicable agreement apply.

12. Contact

Questions about this SLA: legal@brimble.app