On this page

title: fremai Service Level Agreement author: fremverk date: 2026-10-01 version: “1.3” status: Published v1.3 lang: en #

Last updated: 2026-10-01

Effective Date: 2026-08-13 — Version: 1.3 (see the change log for the effective date of each amendment)

This Service Level Agreement (“SLA”) forms part of the Terms of Service between fremverk ApS and the Customer for the fremai service at fremai.eu. Enterprise contracts may set different or additional commitments in an ordering document; in case of conflict, the ordering document prevails.

1. Scope #

This SLA defines the availability commitment for fremai, how availability is measured, what is excluded, the service-credit remedies when the commitment is not met, and how the Customer claims credits.

2. Availability commitment #

2.1 Single-Backend dependency, stated openly #

fremai currently runs on a single EU-sovereign inference Backend (per DPA Annex B). A Backend outage means fremai inference is unavailable, so fremai’s availability tracks the Backend’s closely. fremverk accepts that dependency for now rather than over-building redundancy before product-market fit, and states it openly here and on the status and trust pages rather than leaving it for customers to discover.

fremverk carries that risk rather than passing it to the Customer. The commitment in §2.2 is end-to-end and a Backend outage counts as Downtime; it is not an excluded cause under §4. The Customer’s remedy does not depend on which layer failed.

2.2 Availability target #

fremverk commits to 99.9% Monthly Inference Availability for the in-scope surface defined in §3, measured calendar-monthly (first to last day of the month, UTC).

99.9% per calendar month allows approximately 43 minutes of Downtime in a 30-day month (44 minutes in a 31-day month).

The commitment is measured end-to-end at fremai’s own endpoint, so it covers both fremverk’s proxy and control plane and the inference Backend behind it. fremverk carries the Backend’s availability risk on the Customer’s behalf: a Backend outage is fremai Downtime for the purposes of this SLA and is not an excluded cause under §5.

What the commitment rests on. With a single Backend, fremai cannot be more available than that Backend, and fremverk does not claim that the Backend’s own availability supports 99.9%. The commitment rests on fremverk carrying the risk instead: a Backend outage counts in full as Downtime and is credited under §5 on the same terms as any other. The 99.9% figure is a commercial commitment backed by a financial remedy, not an engineering claim that fremai cannot fall below it.

A second EU Backend remains planned, which will remove the present single-Backend dependency (see DPA Annex A.9). The 99.9% commitment applies now and does not wait for it.

3. In-scope surfaces #

The availability commitment applies to the inference data plane:

Inference API — POST https://api.fremai.eu/v1/chat/completions, /v1/completions, /v1/embeddings, and the other OpenAI-compatible routes the Backend serves.

“Inference availability” means the fremai inference endpoint accepts an authenticated, well-formed, in-budget request and returns either a valid model completion or a valid streamed response — measured by synthetic probes (§4). A request that fails solely because of the Backend’s own unavailability is counted as fremai Downtime, and is remedied under §5 on the same terms as any other Downtime. The Customer does not need to establish which layer failed.

Out of scope (each best-effort and unmeasured under this SLA):

Developer console at app.fremai.eu.
Marketing site at www.fremai.eu and documentation at docs.fremai.eu.
Identity / login surfaces.
Status page at status.fremai.eu — independently surfaced for blast-radius isolation.
Transactional email, payments, and invoicing — subject to the respective sub-processors' own availability.

4. Measurement #

Availability is measured by synthetic external probes against the in-scope endpoint, reused from fremverk’s existing status/probe methodology (updown + Uptime-Kuma) per fremai’s internal design documentation, aggregated calendar-monthly (UTC).
Live status and incident history are published at https://status.fremai.eu.
Excluded from Downtime: scheduled maintenance announced at least 48 hours in advance on the status page; emergency maintenance needed to protect security or integrity; force majeure; Customer-caused errors (invalid requests, exhausted budget → 402, rate-limit 429, exceeded credit limit); and suspension for AUP breach or non-payment.

5. Service credits #

Service credits are the Customer’s sole and exclusive remedy for failure to meet the availability target in §2.2.

If Monthly Inference Availability for a calendar month falls below 99.9%, the Customer is entitled to a service credit against the next invoice:

Monthly Inference Availability	Service Credit (of monthly Fees for the affected month)
≥ 99.9%	0% — commitment met
≥ 99.5% and < 99.9%	10%
≥ 99.0% and < 99.5%	25%
< 99.0%	50%

Service credits are capped at 50% of the monthly Fees for the affected calendar month, regardless of the calculated amount. The bands are those of fremforge’s SLA, which adds a 75% band below 90%. They do not depend on any commitment or remedy fremverk holds against its own Backend: where the Backend’s commitment to fremverk is lower, or its remedy smaller, fremverk bears the difference.

Credits are applied against future Fees, are not redeemable for cash, and do not carry over beyond the term.

6. Claiming credits #

The Customer claims a credit within 30 days of the end of the affected month by contacting fremverk (support@fremai.eu) with the affected dates/times and, where available, the failing request identifiers. fremverk validates the claim against its probe records and applies any due credit to the next invoice or top-up.

7. Changes #

fremverk may update this SLA under Terms §8. That section decides, by a change’s effect on the Customer and not by the direction in which a number moves, whether the change is adverse, and therefore whether it takes effect only after 30 days’ notice with the termination right, or on publication. A change adverse in any respect is adverse as a whole. For this SLA:

Adverse changes include lowering the availability target in §2.2; widening what §4 excludes from Downtime or shortening the advance notice of scheduled maintenance; reducing a credit percentage or the cap in §5; lowering the availability level below which a credit arises; and shortening the claim deadline in §6 or adding conditions to a claim.
Changes that raise a commitment or make a remedy easier to obtain or larger, such as raising the availability target, a credit percentage, or the level below which a credit arises, are not adverse, unless they are adverse in another respect.

The committed target was set in v1.0 and raised in v1.1 ahead of the Phase-2 second Backend, which adds margin against the commitment rather than being a precondition for it.

Change log #

Version	Date	Change
1.3	2026-10-01	§7 now takes the rule from Terms §8 (Terms 1.3), which decides by its effect on the Customer whether a change is adverse and when it takes effect, instead of restating it. §7 keeps the SLA-specific examples. The test is the same as in 1.2, except that Terms §8 also treats an added obligation, restriction or cost for the Customer as adverse and now gives a termination right on an adverse change, so it is not adverse within Terms §8, and takes effect on publication.
1.2	2026-10-01	§7 now defines an adverse change by its effect on the Customer. It sent “material changes” to the Terms §8 notice procedure, which read literally caught a change in the Customer’s favour such as 1.1, a material change that raised the commitment and every credit. A change is now adverse if it reduces a commitment or makes a remedy harder to obtain or smaller, with examples; a change that raises a commitment or makes a remedy easier to obtain or larger takes effect on publication, and an adverse change keeps the 30-day notice in Terms §8. Made in step with Terms 1.2 (§8). No commitment or remedy is reduced, and every adverse change to this SLA now carries the 30-day notice, so it is not adverse within §7 or a material adverse change within Terms §8, and takes effect on publication.
1.1	2026-10-01	Availability commitment raised from 99.5% to 99.9% (§2.2), and the §5 credit schedule moved up with it: 0% at ≥ 99.9%, 10% at 99.5–99.9%, 25% at 99.0–99.5%, 50% below 99.0% (in 1.0: 0% at ≥ 99.5%, 10% at 99.0–99.5%, 25% at 95.0–99.0%, 50% below 95.0%). At every availability level the credit is equal to or higher than under 1.0, and the 50% cap is unchanged. §2.2 now says what a 99.9% commitment on a single Backend rests on: fremverk carrying the Backend’s risk, not the Backend’s own availability. §5 no longer says the bands are “the same shape fremverk holds against its own Backend” so that a shortfall is “passed through on consistent terms”. No record of such terms was found, and a pass-through cannot hold at 99.9% in any case, so it now says fremverk bears any difference. §3 drops “(once set)” and §7 drops the stale expectation that the target would be set when the second Backend lands; it was set in 1.0. Made in step with Terms 1.1 (§6). It raises a commitment and increases every credit, so it is not a material adverse change within Terms §8, and takes effect on publication.
1.0	2026-08-13	First published version. Draft marker removed. Committed availability target set at 99.5% monthly, replacing the Phase-1 best-effort posture, with the 10/25/50% service-credit bands and the 50%-of-monthly-Fees cap. The target is end-to-end: a Backend outage is Downtime and is not an excluded cause. Claim route resolved to `support@fremai.eu`.
0.1	2026-07-06	Initial fremai-specific draft. Phase-1 best-effort/beta; committed uptime target and credit bands left TBD pending launch / second backend. Not published; pending counsel review.