fremforge Service Level Agreement

title: fremforge Service Level Agreement author: fremverk date: 2026-05-25 status: Published v1.2 version: “1.2” lang: en #

Last updated: 2026-05-25

Effective Date: 2026-04-25 — Current Version: 1.2 (effective 2026-05-25; full revision history in §Change log)

This Service Level Agreement (“SLA”) forms part of the Terms of Service between fremverk ApS and the Customer. It applies to the standard fremforge plan at frem.sh. Enterprise-on-Demand contracts may contain different or additional SLA commitments as agreed in an ordering document; in case of conflict, the ordering document prevails.

1. Scope #

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

2. Availability commitment #

2.1 Target #

fremverk commits to 99.5% Monthly Service Availability for the in-scope surfaces defined in §3, measured calendar-monthly (first to last day of each calendar month, UTC).

99.5% per calendar month allows approximately 3 hours 40 minutes of Downtime per month. This commitment is realistic for a service self-healing well under T Cloud’s native redundancy (CCE HPA, RDS cross-AZ automatic failover, ELB-managed certificates) operated by a small team during business hours. Incidents outside business hours are typically resolved automatically or shortly after the next business window.

2.2 Upper bound #

The commitment is deliberately below the composed theoretical ceiling of the T Cloud services in the critical path (RDS, CCE, DCS, OBS, SFS Turbo, ELB — each ~99.9% per-service, lower when composed serially). 99.5% leaves room to absorb a single meaningful T Cloud incident per month without breaching the SLA. Customers requiring stricter commitments should subscribe to the Enterprise-on-Demand tier.

3. In-scope surfaces #

The commitment applies to the following authenticated and unauthenticated production surfaces at frem.sh:

• Forgejo web UI — sign-in, repository browsing, issues, pull requests, wiki, releases, admin console.
• Git over HTTPS — git clone, git fetch, git push at https://frem.sh/<org>/<repo>.git.
• Git over SSH — the same over git@ssh.frem.sh:<org>/<repo>.git at ssh.frem.sh:443 (port 443 mapped to in-cluster SSHd; port 22 is not publicly exposed on the apex domain).
• Package registry API — npm, Maven, Docker, NuGet, PyPI, RubyGems, Composer, Go endpoints at their respective routes under frem.sh.
• Control-plane REST API at frem.sh/_app/api/v1/*.
• fremforge admin UI at frem.sh/_app/<slug>/_admin (per-tenant — URL Option B per plan.md).

Out of scope for the 99.5% commitment (each has its own availability model, stated below):

• Hosted CI runners — best-effort dispatch to T Cloud CCI; measured separately (§4).
• Status page at status.frem.sh — independently hosted in fremforge-status-prd for blast-radius isolation; best-effort and unmeasured under this SLA.
• Marketing site at www.frem.sh — best-effort and unmeasured under this SLA.
• Documentation site at docs.frem.sh — best-effort and unmeasured under this SLA.
• Transactional email — outbound delivery subject to Lettermint B.V. own SLA; inbound shared-mailbox hosting subject to Heinlein Hosting GmbH (mailbox.org) own SLA. fremverk’s own SLA does not extend to either sub-processor’s own service availability.

3A. Audit-log retention by plan #

The two-tier audit retention model in DPA Annex A.7 carries the following SLA floors per plan:

A Customer tenant admin may set the hot-tier retention via Authentication policy → Audit log retention anywhere in the permitted range (presets 90 / 180 / 365 / 730 days; database CHECK enforces 1–730). Setting the hot-tier below the plan’s SLA floor is permitted by the admin UI but disclaims the contractual queryability commitment for the affected period — yes-by-design technical permit, contractual constraint enforced by this SLA. The 3-year WORM hash-chain archive is unilateral and is not customer-tunable downward (see DPA Annex A.7 for the upward-extension request path).

4. Hosted runner dispatch #

fremverk commits on reasonable commercial efforts to dispatch queued CI jobs within 5 minutes of queue entry under normal platform load, subject to the per-organisation fair-use concurrency limits described in the AUP §4 and the global platform concurrency cap. Sustained queue-wait times beyond 5 minutes during nominal platform load are a signal that additional reserved capacity may be warranted — the remedy is commercial, via Enterprise-on-Demand, rather than a service credit under this SLA.

5. Measurement #

5.1 Method #

Availability is measured using synthetic probes (SLI probes) that run from independent EU-hosted locations against the in-scope surfaces. The methodology is summarised on the trust page and applied as follows:

• Multiple probes per surface per minute.
• A three-probe-agreement rule: Downtime is counted only when at least three independent probes from at least two independent locations report failure within the same minute. This prevents a single probe’s transient network issue from inflating the Downtime calculation.
• Probe results and historical availability are published on status.frem.sh with 90 days of on-page history and 3-year internal retention.

5.2 Downtime #

A Minute of Downtime is any minute where the three-probe-agreement rule reports the in-scope surface as failing (HTTP 5xx, connection refused, TLS handshake failure, timeout exceeding 30 seconds, or Git protocol-level failure) on an end-to-end probe.

Monthly Service Availability is computed as:

MSA = ((Total Minutes in Month − Excluded Minutes − Minutes of Downtime) / (Total Minutes in Month − Excluded Minutes)) × 100%

where Excluded Minutes are the minutes excluded under §6.

5.3 Authoritative source #

The measurement recorded on status.frem.sh is the authoritative source for this SLA, supplemented by T Cloud service-health events and fremverk incident records. In case of dispute, fremverk provides raw probe data covering the claimed period on request.

Where the status page itself is unavailable, the authoritative measurement source falls back to T Cloud Cloud Eye (CES) availability data and fremverk’s internal T Cloud LTS observability stack for the affected period. fremverk publishes the fallback data within 7 business days of the incident.

5.3.1 Fallback measurement procedure (P2-SRE-30) #

When the status-page record itself is part of the outage (e.g., a regional-storage event that hits both the customer-facing surface and the status page’s OBS origin), uptime is reconstructed from three independent records, in this order of preference:

1. CES availability metric for each customer-facing ELB / APIG / CCE service (SYS.ELB.healthy_servers, SYS.APIG.api_calls, SYS.CCE.node_status) at 1-minute granularity. CES retains 5 days of 1-minute resolution + 1 year at 5-minute resolution; this scope covers any plausible monthly-billing-cycle reconstruction.
2. LTS log-line presence in the api / Forgejo / runner streams. A continuous gap of >= 60 seconds with zero log lines on a service that normally writes thousands per minute is treated as a full-minute downtime mark for that service.
3. Updown.io external probe history (87 Seconds SARL, France — SIRET 530 700 010 00037; trading as updown.io; EU-only PoPs — a third independent failure domain outside T Cloud). The 5 SEV-1 probes (api healthz, Forgejo, Kuma, marketing, Authentik) at 60s cadence form the third-line authoritative source where CES + LTS are also unavailable. Probe records are exportable per probe via the updown.io API and retained for the SLA-relevant period.

Reconstruction picks the most conservative of the available sources (i.e. the longer downtime number that benefits the customer in a credit calculation). A reconstruction summary is published as a status-page post-incident report within 7 business days; the underlying CES + LTS + updown.io exports are made available to the affected Customer under NDA on request.

If all three sources are simultaneously unavailable for the period (a fremforge-and-T-Cloud-system-of-record-and-EU-external-probe event), fremverk reconstructs from external T Cloud regional-status events plus customer-side reports and treats the reconstruction as a good-faith estimate; the affected Customer may dispute and the dispute is resolved per §11 Service-credit dispute.

5.4 Operator runbooks supporting this section (bidirectional reference) #

The runbooks at runbooks/ in the repository are the operator-side counterpart to this SLA. The bidirectional reference makes the chain auditable: this SLA promises customer outcomes; the runbooks describe the procedures operators follow to deliver them.

Each cited runbook in turn links back to this section (legal/sla.md §5) in its header so an operator opening a runbook understands the SLA commitment driving the procedure.

6. Exclusions #

The following are excluded from the Downtime calculation and do not count against the availability commitment:

6.1 Scheduled maintenance #

Scheduled maintenance announced at least 48 hours in advance via the status page and email to the Customer’s admin-of-record, within the weekly maintenance window of Tuesday 02:00–04:00 UTC. Scheduled maintenance outside the weekly window counts against Downtime unless announced at least 7 days in advance with Customer acknowledgment.

Cap on excluded maintenance. Scheduled maintenance under this clause is excluded from the Monthly Service Availability calculation up to a maximum of 10 hours per calendar month, with a rollover of unused weekly windows up to 12 hours in any single month (so a quiet month carries headroom into a busier one — e.g. a CCE major-version upgrade or RDS engine bump that exceeds the standard 2-hour weekly slot). Maintenance hours beyond the 12-hour ceiling count as Downtime for service-credit purposes. Emergency security maintenance (urgent CVE patching, active-attack mitigation) is excluded without cap, but each instance is reported with a post-incident summary on status.frem.sh within 7 business days.

The 10-hour baseline + 12-hour rollover ceiling supersedes the prior flat 8-hour cap (audit P2-SRE-26, closed 2026-05-09): four 2-hour weekly windows = 8 hours nominal, leaving zero margin for a single over-run on busy months. The new shape gives a 2-hour buffer in normal months and a 4-hour buffer when rollover is available, matching typical operational shape (months are quiet most of the year; bursts come during CVE waves or planned platform-version upgrades).

6.2 Emergency maintenance for security patches #

Out-of-band emergency maintenance required to apply a security patch within the published CVE patch SLA (48h / 72h / 7d / next window), to the extent the patch requires brief service interruption. These windows are minimised wherever possible; security patches are not deferred to honour the weekly maintenance window.

Security-patching commitment (commercially reasonable efforts). During Phase 1, fremverk uses commercially reasonable efforts to patch CVEs against the following targets, measured from upstream fixed release: Critical (CVSS ≥ 9.0) within 72 hours, High (7.0–8.9) within 7 days, Medium (4.0–6.9) within 14 days, Low at the next scheduled maintenance window. From Phase 2 (concurrent with the funded 24/7 on-call rotation, targeted 2027-Q1), fremverk commits to the contractual targets in DPA Annex A.8 (Critical 48h / High 72h / Medium 7d / Low next maintenance). Failure to meet the Phase 1 commercially-reasonable target is not a Service Credit event and is not a material breach for Terms §16.4; failure to meet the Phase 2 targets is a material breach as set out in Terms §13.1.

6.3 Events outside fremverk’s reasonable control #

Force-majeure events outside fremverk’s reasonable control are excluded from Monthly Service Availability calculation only where the event meets the definition of force majeure in Terms §18 as carved out by the listed non-FM events in §18 (in particular, outages of fremverk’s contracted sub-processors — including T Cloud, Bunny CDN, Lettermint B.V., Heinlein Hosting / mailbox.org, Mollie, and Visma Dinero — are NOT excluded as force majeure and remain fremverk’s commercial risk).

• Failures caused by the Customer’s own configuration, usage, or infrastructure — including but not limited to a misconfigured OIDC identity provider, a Customer-owned webhook receiver that is down, DNS changes made by the Customer outside its frem.sh tenant, or Customer-side client issues.
• Failures caused by the Customer’s breach of the AUP or by enforcement actions taken under it.
• Failures caused by a Customer BYO-runner that is down or misconfigured.

6.4 Third-party dependencies not in the critical path #

Excluded from Monthly Service Availability calculation: brief unavailability of third-party services that the Customer has integrated (Customer-configured webhooks, Customer-side IdPs, Customer-side payment failures), and brief unavailability of fremverk’s own non-critical-path third-party providers (e.g. Mollie outages affecting new-signup flows but not existing-tenant Service availability).

7. Service credits #

7.1 Credit schedule #

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

7.2 Cap #

Service credits under this SLA are capped at 50% of the monthly Fees for the affected calendar month, regardless of the calculated amount.

The 50% cap above applies to standard Subscriptions. For severe outages — Monthly Service Availability below 90% in any month — the credit is 75% of monthly Fees for that month. Enterprise-on-Demand Subscriptions may negotiate a 100% credit cap on Order Form.

7.3 Sole remedy #

Service credits are the Customer’s sole and exclusive remedy for breach of this SLA. This clause does not limit fremverk’s liability under the Terms of Service for matters outside the scope of the SLA (for example, a personal-data breach is governed by the DPA and Terms §14.4).

7.4 No cash refund #

Service credits are applied to the next invoice and may not be converted to cash. If the agreement terminates with unused service credits, the credits are applied to any remaining invoice and the balance (if any) is forgone. In the case of termination by fremverk for convenience under Terms §16.3, unused credits are refunded pro rata alongside any prepaid unused Fees.

7.5 Enterprise-on-Demand #

Enterprise-on-Demand contracts may negotiate stricter thresholds (up to 99.95%), a higher credit cap, or additional remedies in the ordering document.

7.6 Chronic breach #

If Monthly Service Availability is below 99.0% for 3 consecutive months or for any 4 months within any rolling 12-month period, the Customer may terminate the affected Subscription for cause by written notice within 30 days of the third (or fourth) qualifying month, with pro-rata refund of any prepaid unused Fees. This termination right is in addition to (not in lieu of) the service credits owed for the qualifying months.

8. Claiming service credits #

8.1 Claim process #

To claim a service credit:

1. The Customer submits a claim via a support ticket to support@frem.sh with subject line starting SLA CREDIT CLAIM and the affected calendar month.
2. The claim includes: the organisation slug, the calendar month concerned, the Customer’s measurement of Downtime or a reference to status.frem.sh, and (optionally) a list of incidents the Customer believes count.
3. fremverk responds within 15 business days with the measured Monthly Service Availability, the applicable credit (if any), and the invoice to which the credit will be applied.

8.2 Deadline #

Claims must be submitted within 30 days of the end of the affected month. The deadline is extended to 90 days where fremverk has published a post-mortem on status.frem.sh for the underlying incident; in that case the post-mortem URL is sufficient evidence for the claim.

8.3 Good-faith cooperation #

The Customer is expected to cooperate in good faith and not double-count incidents, claim for excluded minutes, or claim for failures on the Customer’s side of the integration boundary. fremverk will publish incident post-mortems on the status page for incidents affecting availability to allow Customer cross-reference.

9. Incident communication #

During an active incident affecting any in-scope surface in §3, fremverk commits to:

• On-call acknowledgement within 1 business hour during business hours (09:00–17:00 Europe/Copenhagen, Mon–Fri excluding Danish public holidays); best-effort outside business hours via the on-call rotation published on status.frem.sh. Acknowledgement is the operator confirming receipt of the page and beginning triage; it is not a commitment to a resolution time. Enterprise-on-Demand Subscriptions may negotiate tighter ack windows in the Order Form, subject to the funded 24/7 rotation availability noted under Support Response Times.
• Two-person on-call rotation — primary and secondary operator on the documented rota at all times. Either operator can ack a Severity-1 page; the rotation is sized so a single-operator absence (holiday, sick day) does not extend the ack window.
• Status-page update within 15 minutes of on-call acknowledgement of the incident at status.frem.sh, with a plain-English description of the affected surface and the observed impact. The status page is hosted in an independent enterprise project (fremforge-status-prd) and is designed to stay up when the product surface is down.
• Status-page updates at least every 30 minutes for the duration of the incident, or more frequently if material new information becomes available.
• Email notification to the admin-of-record of each affected organisation for Severity 1 incidents (complete unavailability of one or more in-scope surfaces for > 15 minutes) — initial notification within 30 minutes of acknowledgement, and an all-clear message at resolution.
• Post-mortem publication on the status page within 14 days of resolution of any incident affecting Customer data or availability, documenting timeline, root cause, and corrective actions.

Status-page data is retained 90 days on-page and 3 years internally for verification against this SLA and against any §8 credit claim.

Status-page events are exposed at status.frem.sh/feed.atom (RSS/Atom) and status.frem.sh/api/v1/incidents (JSON), and Customer-configured webhooks may subscribe at frem.sh/_app/<slug>/_admin/webhooks/incidents. fremverk’s contractual notification commitment under DPA §8 and §9 of this SLA is satisfied where notice reaches the Customer through any of: (a) the Customer’s nominated security-contact email, (b) a Customer-configured webhook subscription, (c) RSS/Atom feed subscription that the Customer has documented as in-use, OR (d) the trust-page banner where the incident is platform-wide.

10. Support #

Standard support hours: 09:00–17:00 Europe/Copenhagen, Monday to Friday, excluding Danish public holidays. P1 support is 24/7 regardless of standard hours.

The 99.5% commitment is paired with email support via support@frem.sh. Target first-response times:

P1 — Service unavailable for all Users:

• Standard Subscription: first response within 1 business hour during 09:00–17:00 Europe/Copenhagen on business days; best-effort outside business hours via the on-call channel published on status.frem.sh.
• Enterprise-on-Demand Subscription: first response within 1 hour, 24/7, including weekends and Danish public holidays. Subject to fremverk’s funded on-call rotation, available from 2027-Q1; until then, the Standard Subscription terms apply with commercially reasonable best-effort 24/7.

fremverk self-assigns severity on receipt; the Customer may request re-triage. Severity is not a guarantee of resolution time.

Enterprise-on-Demand contracts add 24/7 P1 response with a named Customer Success contact.

11. Security-patching SLA (cross-reference, not part of availability measurement) #

The published security-patching SLA at trust page §Security patching and in the DPA security annex §A.8 is a contractual commitment separate from the availability commitment in this SLA. It is not measured by service credits but by published adherence on the trust page and — for regulated customers — by the DPA security annex. Brief windows of interruption to apply a security patch within SLA are excluded from Downtime (§6.2).

12. Changes to this SLA #

fremverk may update this SLA subject to the 30-day-notice requirement in Terms of Service §17. Changes that reduce the availability commitment, raise thresholds, reduce credit rates, or weaken the incident-communication commitment in §9 are considered material and adverse, and give the Customer a termination right without penalty under Terms §17.

13. Contact #

• Claims: support@frem.sh (subject line: SLA CREDIT CLAIM — <month>)
• Escalation and contract queries: compliance@frem.sh

Change log #