service level agreement

last updated 2026-08-20 · briven.tech

briven publishes no uptime percentage, and Section 1 sets out why. What it commits to instead is a list of operational practices that can be checked rather than believed — because a promise you can verify is worth more than a promise you cannot.

1. There is no uptime guarantee, and here is why

briven does not currently offer a contractual availability percentage, and does not offer service credits. Unless you have a separate written agreement signed by flndrn Limited, the Service is provided without a guaranteed uptime figure, as stated in Section 8 of the Terms of Service.

Three plain reasons:

• One region, one machine. The whole platform runs as a single deployment. There is no multi-region failover. Read replicas and autoscaling exist, and they live on this same machine, so they do not turn a machine-level failure into a non-event. A percentage that pretended otherwise would be a number nobody can honour.
• A small independent company. flndrn Limited is not a company with a follow-the-sun rota. Committing contractually to a recovery time nobody is rostered to meet at 04:00 would be a promise made to look good on a page.
• Nothing measures it well enough yet. This is the real one. briven does not have availability measurement over a meaningful period, and a number nobody measures is a number nobody can honour. Publishing one would not make the Service more reliable; it would only make the page less true.

If a written, negotiated SLA with defined targets and credits is a requirement for you today, briven is not the right choice yet, and we would rather you knew that before you migrated than after. See §7 for how to start that conversation anyway.

2. What briven does commit to

Every item below is a practice that already exists and can be checked, not an aspiration.

• Nightly backups with continuous archiving. A full backup runs every night at 02:00 UTC, and write-ahead-log archiving runs continuously between them, using pgBackRest. Seven full backups are retained.
• A restore that is drilled monthly. On 19 August 2026 a restore of briven’s own control database recovered a row that existed in no backup file — it came out of the write-ahead log. On 8 September 2026 the same path was rehearsed on a throwaway customer database: a token written after last night’s backup came back from the diary into a spare copy, in about 12 seconds, without touching the live database. A backup nobody has restored from lately is a hope; this one is exercised on a schedule. Next drill due 8 October 2026. Restore stays a person, not a timer, because a restore pointed at the live path would overwrite.
• Restores never overwrite. A restore always lands in a new database beside the original, never on top of it. Recovering from a mistake cannot itself become a second, larger mistake, and you can compare the two before you cut over.
• A public status page. Current platform state is published at /status, open to anyone, with no account needed.
• A health endpoint the platform reports from. The status page is not a hand-updated notice board: it reads a health endpoint that the platform itself answers, so what you see is what the system says about itself.
• Security fixes ship immediately. A security patch is not held for a release window. It goes out as soon as it is ready, and the announcement follows the change rather than gating it.
• Material changes are announced. Changes that break documented behaviour are announced with reasonable notice where possible, in line with Section 8 of the Terms.

One honest limit on the backups. A second copy of every backup is taken to another machine every night. On 8 September 2026 a throwaway customer database was restored from that other machine into a spare copy. That protects you if this machine’s own backup store is lost. It is still not automatic protection if the whole machine is gone — someone has to restore onto a new box. Keep your own pg_dump: the data is standard PostgreSQL, so a dump over your normal connection is a complete, portable copy taken on your schedule and held where you choose.

3. Maintenance

briven does not reserve a weekly maintenance window, because reserving one implies routine downtime that the platform does not in fact take. Most changes — dashboard releases, API changes, configuration — ship without interrupting database connections.

Where a change genuinely requires an interruption, such as a PostgreSQL upgrade or work on the connection pooler, the approach is: announce it in advance on /status where the timing is ours to choose, schedule it into low-traffic hours, keep it as short as the work allows, and post when it is finished. Emergency security work is the exception and may go out immediately with the notice following, because a disclosed vulnerability left open for a maintenance window is the worse outcome.

4. When there is an incident

An incident is any unplanned event that degrades or interrupts the Service. Here is what happens and where you will see it.

• Where it is posted. /status is the single source of truth during an incident. It is the first place updated and the last place closed out.
• What the first update says. What is affected, what the symptom looks like from your side, and that it is being worked on — published as soon as the problem is confirmed, without waiting for a cause. The Operator will not sit silent while it diagnoses.
• What later updates say. What is now known, what has been tried, and whether there is a workaround. Where a cause is not yet understood, the update will say that rather than guess.
• When your data is involved. If an incident affects customer data, the Operator notifies affected accounts by email without undue delay, and provides what it knows at the time. Personal-data breach handling is governed by §10 of the Data Processing Agreement.
• Afterwards. For material incidents the Operator publishes a write-up within 30 days: what happened, what the impact was, and what changed so it is less likely to happen again.

To report something that looks like an incident, write to support@flndrn.com. For anything with a security dimension, write to security@flndrn.com instead — see the security page for disclosure practice.

5. What is excluded in any case

Even where a written SLA is later agreed, the following would sit outside it, and they are listed here so the boundary is clear now: your own application code, schema and queries; loss caused by credentials you exposed; your network or your end users’ connectivity; third-party services you call from your application; suspension under Section 5 or 10 of the Terms or under the acceptable use policy; and events outside the Operator’s reasonable control.

6. What would have to be true before briven promises a number

The absence of a percentage is a decision rather than an oversight. Three things have to be true, and all three, before a figure could be published honestly:

• Measurement over a meaningful period. Availability recorded continuously, from outside the platform as well as inside it, over months rather than days — long enough that the number describes normal operation and not a quiet week. Without this, any figure is a guess with a decimal point on it.
• Off-site backups. A copy of the backup repository on separate infrastructure, so that recovery survives the loss of the machine and not only the loss of a table. A restore promise that depends on the failed machine still existing is not a recovery guarantee.
• More than one machine. Somewhere for the Service to be while the primary is unavailable. Until that exists, the honest recovery story is “restore from backup”, and that has a duration measured in the size of your data, not in the nines of an SLA.

When those are in place, this page will publish a figure that has been measured rather than chosen, and this section will describe how it was earned. Until then, these are the conditions that stand between briven and a number.

7. Enterprise agreements

If your organisation requires a written, negotiated service level agreement — defined availability targets, recovery objectives, response times, service credits — write to legal@flndrn.com. That would be a separate signed agreement between your organisation and flndrn Limited, negotiated on its own terms and priced accordingly; it would prevail over this page for the customer that signs it. This page is not that agreement and does not become one by being read, and nothing on it creates a contractual service level.

8. Related documents

Security mechanisms and their limits: /security. Current platform state: /status. How the platform is built and operated: /trust. The contract itself: /terms. Personal-data processing: /dpa.