On this page

Last updated: 2026-10-06

Effective Date: 2026-04-25 — Current Version: 1.14 (effective 2026-11-03; until then version 1.11 applies; 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.9% Monthly Service Availability for the in-scope surfaces defined in §3, measured calendar-monthly (first to last day of each calendar 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). That is shorter than an operator response outside business hours, where on-call acknowledgement is best-effort (§9). The commitment therefore rests on the service recovering automatically under T Cloud Public’s native redundancy (CCE HPA, RDS cross-AZ automatic failover, ELB-managed certificates), not on human intervention. An incident outside business hours that does not recover automatically will usually use up a month’s allowance on its own, and the Customer is then entitled to a service credit under §7.

2.2 Relationship to the underlying platform #

The commitment is above the composed theoretical ceiling of the T Cloud Public services in the critical path, not below it. Those services (RDS, CCE, DCS, OBS, SFS Turbo, ELB) are each published at about 99.9% per service; composed serially, the published figures multiply out to about 99.4%. Up to version 1.5 this section said the commitment was deliberately set below that ceiling. At 99.9% that is no longer true, so this section now states what the commitment rests on instead.

It rests on two things:

Measurement is end-to-end. A per-service figure is a provider’s contractual floor, not its measured availability, and Downtime under this SLA is counted only when the end-to-end probes in §5 fail. A dependency fault that the redundancy described in §2.1 absorbs is not Downtime.
fremverk carries the dependency risk. Where a dependency fault does reach the Customer, it counts in full: outages of T Cloud Public and fremverk’s other contracted sub-processors are not excluded (§6.3), and the service credits in §7 apply on the same terms whichever layer failed.

The 99.9% figure is therefore a commercial commitment backed by a financial remedy, not an engineering claim that the platform cannot fall below it. Customers whose own obligations require more than a service credit should discuss Enterprise-on-Demand terms.

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 the platform’s SSH service; 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/<slug>/_admin (per-tenant — URL Option B per fremverk’s internal product plan).

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

Hosted CI runners — best-effort dispatch to ephemeral T Cloud Public Elastic Cloud Server virtual machines; measured separately (§4).
Status page at status.frem.sh — hosted in a separate, isolated cloud project 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:

Plan	Queryable hot-tier (default)	Queryable hot-tier (SLA floor)	WORM hash-chain archive
Standard	90 days	90 days	3 years
Enterprise-on-Demand / the operator-provisioned custom trial / internal	365 days	365 days	3 years

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 Public 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 Public Cloud Eye (CES) availability data and fremverk’s internal T Cloud Public 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:

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.
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.
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 Public). 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 Public 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 procedures #

fremverk maintains written operator procedures for delivering the commitments in this SLA, covering incident response, status-page and post-incident publication, the restore drills in DPA Annex A.9, a T Cloud Public regional outage, and deploy rollback during an incident. They are available to Customers under NDA on request via compliance@frem.sh. The incident-communication and post-mortem templates are public at docs.frem.sh/runbooks/incident-comms-template and docs.frem.sh/runbooks/post-mortem-template.

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 — contractual, in force now), 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 (contractual). fremverk patches CVEs against the following targets, measured from the upstream fixed release or advisory publication (whichever is later): Critical (CVSS ≥ 9.0) within 48 hours, High (7.0–8.9) within 72 hours, Medium (4.0–6.9) within 7 days, Low (< 4.0) by the next scheduled maintenance window. These are contractual and in force now. The previous phased model — weaker targets under commercially reasonable efforts until 2027-Q1 — was withdrawn on 2026-08-05 because fremverk’s published trust page already stated the stricter figures as a commitment, and DPA Annex A.8 incorporates that page by reference. See DPA A.8 (v1.30).

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 Public, 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.9%, the Customer is entitled to a service credit against the next invoice:

Monthly Service 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%

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.5% 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:

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.
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.
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. 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.
On-call coverage — fremverk maintains a documented on-call rotation, with cover for absence, sized to meet the acknowledgement and response targets in this section and §10.
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 a separate, isolated cloud project 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/<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 (“business hours”): 09:00–17:00 Europe/Copenhagen, Monday to Friday, excluding Danish public holidays. A P1 may be reported at any time; outside business hours its first response is best-effort, as set out below.

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

P1 — Critical (defined in §10.1): first response within 1 hour during business hours (09:00–17:00 Europe/Copenhagen, Monday to Friday, excluding Danish public holidays), best-effort outside business hours. Contracted 24/7 P1 response (1 hour, including weekends and Danish public holidays) is available from 2027-Q1 for Enterprise-on-Demand Subscriptions.

Standard Subscription: as above. Outside business hours a P1 is reported to support@frem.sh in the same way, and the response is best-effort.
Enterprise-on-Demand Subscription: from 2027-Q1, first response within 1 hour, 24/7, including weekends and Danish public holidays, subject to fremverk’s funded on-call rotation. Until then, the Standard Subscription targets apply, with commercially reasonable best-effort response outside business hours.

10.1 Support targets #

Each severity has a first-response target, and P1 to P3 also have a workaround and a resolution target. This table is the support commitment; the support page at docs.frem.sh restates it and does not change it.

Severity	Definition	First response	Workaround	Resolution
P1 — Critical	The Service, or an in-scope surface in §3, is unavailable for all Users, or for all Users of the Customer’s organisation; no User of the organisation can authenticate; or Customer data is at risk of loss	1 hour during business hours; best-effort outside business hours	4 business hours	2 business days
P2 — High	Major functionality degraded or unavailable, for example hosted runners down or single sign-on failing for most Users	4 business hours	2 business days	10 business days
P3 — Medium	Minor issue or question: degraded performance, a problem affecting a single User, any non-blocking issue, or a question about using the Service	1 business day	5 business days	20 business days
P4 — Low	Feature request, documentation	3 business days	—	—

First response is a reply from a person at fremverk who has read the request, states the severity assigned and says what happens next.
Workaround means the Customer can use the affected function again, in full or by an alternative fremverk has described, or the Service is restored.
Resolution means the cause is fixed in the Service, or, for a question, the question is answered. Where the cause lies outside fremverk’s control (§6.3, §6.4) or on the Customer’s side, resolution means fremverk has done what is in its control and has told the Customer what remains.
Workaround and resolution targets run from receipt of the request at support@frem.sh and count business hours and business days only, so outside business hours they wait for the next business hour. They pause while fremverk waits for information it has asked the Customer for.
P4 has no workaround or resolution target: feature requests are considered for the roadmap without a commitment, and documentation errors are corrected in the published documentation.
Missing a workaround or resolution target does not by itself give rise to a service credit; service credits arise under §7.

fremverk self-assigns severity on receipt; the Customer may request re-triage.

Enterprise-on-Demand contracts add a named Customer Success contact and, from 2027-Q1, contracted 24/7 P1 response.

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 under Terms of Service §17. 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 commitment in §2.1; widening an exclusion in §6 or raising the maintenance cap; reducing a credit percentage or the cap in §7; lowering the availability level below which a credit or the §7.6 termination right arises; shortening the claim deadline in §8.2 or adding conditions to a claim; and weakening the incident-communication commitment in §9.
Changes that raise a commitment or make a remedy easier to obtain or larger, such as raising the availability commitment, a credit percentage, or the level below which a credit or the §7.6 termination right arises, are not adverse, unless they are adverse in another respect.

13. Contact #

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

Change log #

Version	Date	Change
1.14	2026-10-06	Effective 2026-11-03. Widening only. §10 support targets: one table of severity, first response, workaround and resolution, which the support page at docs.frem.sh restates without change (SKI 02.06 K65–K66). §10 gave first-response targets only and said severity was not a guarantee of resolution time. New §10.1 adds a workaround target and a resolution target for each severity (P1: 4 business hours and 2 business days; P2: 2 and 10 business days; P3: 5 and 20 business days; P4: none), defines first response, workaround and resolution, and says when the workaround and resolution clocks run and pause. The severity definitions now include the examples the support page used (no User of the organisation able to authenticate, Customer data at risk of loss, hosted runners down, single sign-on failing for most Users, a problem affecting a single User), so a request is classified the same way in both places; each definition covers at least what it covered before. Every first-response target, the business hours, the best-effort P1 response outside them, the 2027-Q1 Enterprise-on-Demand 24/7 P1 response and the §9 acknowledgement targets are unchanged. It adds commitments and removes none, so it is not adverse under ToS §17 or SLA §12 and needs no notice. Queued for 2026-11-03 behind 1.13, whose text it contains: on that day 1.14 applies, and 1.13 is never in force on its own.
1.13	2026-10-04	Effective 2026-11-03. Materially adverse. Announced by notice effac7b9-0802-48f2-af88-f11fc4462fa6 on 2026-10-04 (as sla 1.13). §9 — on-call coverage stated as an outcome, not as staffing. 1.12 (effective the same day) describes the on-call rota by headcount: two operators in business hours, one outside, the secondary covering around the clock when the primary is absent. 1.13 replaces that with an outcome: fremverk maintains a documented on-call rotation, with cover for absence, sized to meet the acknowledgement and response targets in §9 and §10. The SLA no longer states how many operators are on call or when. Every acknowledgement, response, status-page and notification target is unchanged. Materially adverse under ToS §17 and SLA §12, because it removes a stated staffing commitment, so it takes effect on 2026-11-03, 30 days after the notice sent on 2026-10-04, with the §17 termination right. Until then version 1.11 applies, as it does for 1.12.
1.12	2026-10-04	Effective 2026-11-03. Materially adverse. Announced by notice 999f05a2-d9ea-4be3-a423-59fd1e9354b0 on 2026-10-04 (as sla 1.11). The 2026-10-04 notice announced this change as sla 1.11: those numbers were taken the same day by a clarification (#145, internal names become descriptions), which was already published when the notice went out, so this change carries the next number. Same change, same effective date. §9 on-call coverage as staffed: two operators in business hours (the secondary is paged after 15 minutes without acknowledgement), one, the primary, outside business hours; the secondary is on call around the clock when the primary is absent. Was “two-person on-call rotation … at all times”. Acknowledgement targets unchanged. No infrastructure change: this describes the backup lifecycle and the rota that operate.
1.11	2026-10-04	Internal implementation names replaced by descriptions. §5.4 listed operator runbooks by file name; it now describes the procedures fremverk keeps and how a Customer obtains them (under NDA via `compliance@frem.sh`), and keeps the links to the two public templates. §3 and §9 named the status page’s cloud project; they now say it is hosted in a separate, isolated cloud project. §3 says “the platform’s SSH service” instead of an internal component name. No commitment, target, measurement method or remedy changes, so this is a clarification, not materially adverse under ToS §17 or SLA §12, effective on publication.
1.10	2026-10-03	§10 support targets stated once, the same way everywhere, and matched to the rota that is staffed. §10 said both “P1 support is 24/7 regardless of standard hours” and that the P1 first response outside business hours is best-effort, and the support page at docs.frem.sh gave 2 business hours for P1. The commitment is now one sentence, used identically in the docs: P1 first response within 1 hour during business hours, best-effort outside business hours; contracted 24/7 P1 response from 2027-Q1 (Enterprise-on-Demand). A P1 may still be reported at any time. §9 and §10 no longer say the out-of-hours channel or rotation is published on `status.frem.sh`, which it is not; out of hours a P1 goes to support@frem.sh as in hours. The closing Enterprise-on-Demand line now carries the 2027-Q1 date its own bullet already had. No target changes — the 1-hour business-hours target, the best-effort out-of-hours response, P2–P4 and the 2027-Q1 date are as before — so this is a clarification, not materially adverse under ToS §17, effective on publication.
1.9	2026-10-01	§12 now takes the rule from Terms §17 (Terms 1.10), which decides by its effect on the Customer whether a change is adverse and when it takes effect, instead of restating it. §12 keeps the SLA-specific examples of adverse and not-adverse changes. The test is the same as in 1.8, except that Terms §17 also treats an added obligation, restriction or cost for the Customer as adverse, so it is not adverse within Terms §17, and takes effect on publication.
1.8	2026-10-01	§12 now defines an adverse change by its effect on the Customer. It had listed “raise thresholds” as adverse, which read literally covered 1.7, where raising the §7.6 termination threshold made the remedy easier to reach. A change is now adverse if it reduces a commitment or makes a remedy harder to obtain or smaller, with examples that include lowering the level below which a credit or the termination right arises; a change that raises a commitment or makes a remedy easier to obtain or larger takes effect on publication. Every change that reduces a commitment or makes a remedy harder to obtain or smaller is still adverse, the list now also covers changes the old wording missed (an exclusion widened, a claim deadline shortened), and the 30-day notice and termination right in Terms §17 are unchanged. Only a change in the Customer’s favour, which the old wording caught by its literal terms, is no longer adverse, so it is not adverse within §12 or materially adverse within Terms §17, and takes effect on publication.
1.7	2026-10-01	§7.6 chronic-breach termination threshold raised from 99.0% to 99.5%. The for-cause termination right with pro-rata refund now arises when Monthly Service Availability is below 99.5% (was 99.0%) for 3 consecutive months, or for any 4 months in a rolling 12-month period. The month counts, the 30-day exercise window and the refund are unchanged. 99.5% is the bottom of the 10% credit band that 1.6 introduced, so the right now arises from the band in which a month already earns more than the minimum credit. It makes the remedy easier to obtain and removes nothing a Customer could do under 1.6, so it is not adverse within §12 of this SLA or materially adverse within Terms §17, and takes effect on publication.
1.6	2026-10-01	Availability commitment raised from 99.5% to 99.9% (§2.1, §3, §7.1, §10), and the §7.1 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.5: 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.5. The 50% cap, the 75% severe-outage credit below 90% (§7.2) and the 99.0% chronic-breach threshold (§7.6) are unchanged. §2.2 rewritten: it said the commitment was deliberately below the composed ceiling of the T Cloud Public services in the critical path, which stops being true at 99.9% (six services at ~99.9% each compose serially to ~99.4%). It now says the commitment is above that ceiling and rests on end-to-end measurement plus fremverk carrying dependency risk through §7. §2.1 now says that a 43-minute monthly allowance is shorter than an out-of-hours response, so the commitment depends on automatic recovery. Made in step with Terms 1.9 (§11). It raises a commitment and increases every credit, so it is not materially adverse within Terms §17 or §12 of this SLA, and takes effect on publication.
1.5	2026-08-05	Security-patching commitment moved from commercially reasonable efforts to contractual. §6.2 now states Critical 48h / High 72h / Medium 7 days / Low next maintenance window, in force now, replacing the phased model that had weaker Phase 1 targets until 2027-Q1. Made in step with DPA 1.30 and Terms 1.6: fremverk’s published trust page already committed to these figures and DPA Annex A.8 incorporates that page by reference, so the phasing had the contract promising less than the public page. Resolved in the Customer’s favour — every target moves in their favour and none is weakened.
1.4	2026-08-04	Corrected the hosted-runner platform: runners are ephemeral T Cloud Public Elastic Cloud Server virtual machines, one per job, not Cloud Container Instance containers. The CCI model was pre-launch intent and never shipped; `cce-node-image` was archived 2026-06-24. DPA Annex A.5 was corrected on 2026-08-04 but this document was not, because the regression guard added at the time checked only the DPA. No control is weakened — per-job VMs give strictly stronger isolation than shared-kernel containers, so the substance (no shared kernel between tenant jobs) is unchanged and now accurately described. Not materially adverse under the Terms §1.2 test.
1.0	2026-04-25	Initial publication.
1.1	2026-05-08	Round-7 substantive updates: §5.3 fallback measurement source corrected from “Loki/LTS” to “T Cloud Public LTS” (we don’t run Loki — P2-LEG-25); §5.3.1 fallback measurement procedure added documenting the CES 1-min metrics + LTS log-line presence reconstruction path (P2-SRE-30).
1.2	2026-05-25	New §3A “Audit-log retention by plan” documenting the per-plan SLA floor (standard = 90d queryable + 3y WORM; enterprise = 365d queryable + 3y WORM baseline). Mirrors DPA v1.14 + DPIA v1.2. The Customer admin may set hot-tier retention below the plan SLA floor via the admin UI but doing so disclaims the contractual queryability commitment for the affected period — yes-by-design split between technical permit and contractual constraint.
1.3	2026-08-04	Audit-retention tables: the plan name `enterprise_trial` no longer exists. Migration 0164 renamed the `plan_tier` enum value to `custom_trial`; the retention tables in DPA A.7, SLA §3A and the ROPA were not updated and had named a plan for ~2.5 months that no system recognises. Now described as “the operator-provisioned custom trial” rather than by an internal identifier, so a future enum rename cannot make the contract wrong again — naming an implementation detail in a customer document is what created this. No retention value, floor or default changes; this is the same plan under an accurate description, so it is not materially adverse and takes effect on publication. Found while verifying the 365-day default itself, which turned out not to be implemented at all (fixed in monolith #1271 and backfilled across 7 tenants); the stale name was the smaller half of that finding.