RaposaService Level Agreement
This document applies to the Team and Business plans. The Sandbox plan is provided as-is and carries no commitment.
Every number below is one we measure, not one we hope for. Where a figure comes from a measurement, the measurement is named.
1. Availability
We commit to 99.5% availability per calendar month for the API
(/v1/*) and the approval console. That allows for 3 hours 39 minutes of downtime in
a 31-day month.
| What | Commitment | How it is measured |
|---|---|---|
| Availability | 99.5% / calendar month | An external monitor on a host in another country, outside our hosting provider, checks eight endpoints every five minutes. A check that runs on the same machine goes down with it and reports nothing. |
| Time to detect an outage | 5 minutes or less | The monitor interval. It also verifies that the console still demands a password and that the payment webhook still refuses unsigned events — if either stops being true we treat it as an incident of the same size. |
| Status of a check | HTTP response code | An endpoint is down when it does not return its expected code, or does not answer within 20 seconds. |
2. Data loss and recovery
| What | Commitment | How it is measured |
|---|---|---|
| Maximum data loss (RPO) | 5 minutes | An encrypted copy of the database leaves the primary host every five minutes to a second host in another country inside the EEA. Each copy is checked before it is sent and checksum-verified after it lands. |
| Recovery time (RTO) | Target 60 minutes | The technical part is measured: from encrypted copy to a running, verified service takes 8 seconds. The rest is a human deciding the primary is genuinely gone, plus DNS propagation at a 300-second TTL. We do not fail over automatically, and we say why in section 6. |
| Integrity of the audit chain | Verifiable at any time | Every restore drill recomputes the hash chain end to end. A restore that does not verify is not a restore. |
3. Measured capacity
Load-tested on the production machine against a copy of the production database — same cores, same storage, same single worker — on 24 August 2026:
| Concurrent requests | Throughput | p50 | p95 | p99 | Errors |
|---|---|---|---|---|---|
| 10 | 410 / second | 20 ms | 47 ms | 64 ms | 0 |
| 50 | 149 / second | 203 ms | 894 ms | 1.3 s | 0 |
| 100 | 127 / second | 377 ms | 2.9 s | 4.8 s | 0 |
| 200 | 94 / second | 1.4 s | 5.6 s | 7.0 s | 0 |
| 400 | 85 / second | 3.4 s | 12.9 s | 17.4 s | 2 of 2000 |
Read that table honestly: throughput peaks at low concurrency and falls as concurrency rises. Past roughly ten simultaneous requests, more parallelism buys latency, not capacity. Nothing was lost or corrupted at any level, and twenty operators deciding the same approval at the same moment produced exactly one decision and nineteen conflicts, as designed.
We therefore commit to p99 under 250 ms for approval creation at up to the rate your plan allows. Those rates are not one number for everyone — a plan that sells volume has to allow the speed to use it:
| Plan | Requests per minute | Which is |
|---|---|---|
| Sandbox | 60 | 1 per second |
| Team | 600 | 10 per second |
| Business | 1 200 | 20 per second |
Above your rate the API answers 429 with the ceiling for your plan and a
Retry-After header saying when to come back. That is not downtime, and it does not
count against availability.
4. Response times
| Severity | Meaning | Team | Business |
|---|---|---|---|
| Critical | API or console unavailable, or approvals cannot be decided | 1 business hour | 30 minutes, any day |
| High | A function is broken, a workaround exists | 1 business day | 4 business hours |
| Normal | Question, change request, minor defect | 3 business days | 1 business day |
Business hours are 09:00–18:00 Europe/Madrid, Monday to Friday, excluding Spanish public holidays. Response time means a human answering, not an automated receipt.
5. What does not count as downtime
- Planned maintenance announced by email at least 48 hours in advance, up to 4 hours per month.
- Failures caused by the customer's own configuration, credentials or webhook endpoint.
429responses from exceeding the plan quota or the per-key rate limit.- Outages at a third party we depend on and name openly: Stripe, Resend, Cloudflare, OVHcloud.
- Force majeure, or a legal order that requires suspension.
6. What this SLA does not promise
A commitment is only worth something if its limits are stated in the same document.
- No automatic failover. The standby is promoted by a person, deliberately. Two instances running at once would split the audit chain into two branches with no way to merge them — worse for a customer who needs evidence than an hour of downtime.
- No zero data loss. Up to five minutes of decisions can be lost in a total loss of the primary host. We will tell you the exact timestamp of the recovered copy.
- One primary host. The service runs in Germany; the encrypted standby copy is in France. Both inside the EEA. Neither is a multi-region cluster, and we will not describe it as one.
7. Service credits
If availability in a calendar month falls below 99.5%, you may claim a credit against the following month:
| Availability in the month | Credit |
|---|---|
| 99.0% – 99.49% | 10% of the monthly fee |
| 95.0% – 98.99% | 25% of the monthly fee |
| Below 95.0% | 50% of the monthly fee |
Credits are the sole remedy under this SLA. They are applied to future invoices and are not paid out in cash.
8. How to claim
Write to contact@raposa.group within 30 days of the end of the affected month, with the dates and times you observed and any evidence you have (error responses, timestamps, your own monitoring). We answer with our monitoring record for the same period, whether or not it supports the claim.
9. Changes
We may update this document. Any change that reduces a commitment takes effect no earlier than 30 days after we email you about it, and never during a month already in progress.