StorkHost — Service Level Agreement
Last updated: 2026-06-25 · Status: Beta · Companion to tos.md
The point of this SLA is to promise something concrete — modest, but real, and honestly stated. It applies to your use of StorkHost during beta and sits under the Terms of Service.
1. Scope — what this SLA covers
This SLA distinguishes two layers, because they have very different reliability profiles:
- Control plane (the platform): the API, MCP endpoint, signup/auth, billing and metering ledger, and the deploy/build pipeline. These are operated by StorkHost and are the subject of our availability commitment below.
- Tenant workloads (your apps): the containers, functions, and static sites you deploy. Their availability depends heavily on your code, configuration, resource sizing, and balance. We provide the runtime and isolation; we do not guarantee the availability of any individual tenant workload, and workload-level issues caused by your own code or configuration are out of scope (see §5).
2. What we do not promise
We do not offer a hard, contractual uptime guarantee (no five-nines, no SLA percentage you can litigate) during beta. A tiny independent beta host that claims enterprise uptime is not being honest. Instead of a number we can't honor, we make the concrete operational promises below, and we publish our actual track record on the public status page.
3. Availability target (control plane)
We target 99.5% monthly availability of the control-plane API, measured as successful responses to the platform health endpoint, excluding the exclusions in §5. This is a target and best-effort objective during beta, not a contractual guarantee. It exists so you know what "good" looks like and so our status page can be measured against it.
4. What we do promise
1. Best-effort operation, no service credits during beta. The operative SLA during beta is best-effort with no contractual service credits. We do not offer compensation, account credits, or refunds for downtime while StorkHost is in beta. The concrete, honest promises we do make are the notice, transparency, and post-mortem commitments below. (A tiered service-credit scheme is a post-beta target, not currently offered — see the appendix.)
2. Advance notice of maintenance. Planned maintenance windows are declared at least 24 hours in advance via the status page and/or email. The only exception is urgent, emergency outage-remediation work — we perform that immediately and disclose it afterward.
3. Transparency during incidents. We do not go dark mid-incident. Outages are posted to the public status page, kept updated while we work, and followed by an honest post-mortem. The status page is this SLA's evidence surface.
4. Upstream stability, inherited not resold. StorkHost runs on third-party infrastructure that carries its own network/power SLA. We benefit from that, but we do not re-sell it as our own contractual number — our promise to you is the operational and transparency commitments above.
5. Exclusions — what this SLA does not cover
- Issues caused by your own actions, code, configuration, resource sizing, or dependencies.
- Tenant-workload-level outages that are not caused by a control-plane failure.
- Events beyond our reasonable control — force majeure, broad internet disruptions, DNS/registrar issues, or upstream-provider outages outside our remediation.
- Workloads suspended or terminated for a Terms-of-Service / Acceptable-Use violation.
- Any period during which your credit balance was zero and the workload was stopped for non-payment, or during which a free-tier workload was preempted or reached its trial TTL.
- Beta features explicitly labeled experimental or preview.
- Scheduled maintenance announced under §4(1).
6. Support channels
During beta, support is provided by email at support@storkhost.cloud. There is
no phone line and no ticketing-response SLA. We read the inbox and reply, but we
do not commit to a fixed first-response time during beta. The status page is the
canonical source for current platform health and incident history.
7. Beta disclaimer
These SLA terms, targets, and remedies may change during beta. Changes are announced via the status page and/or email. See tos.md for the full service terms this SLA sits under.
Appendix — post-beta service-credit target (NOT currently offered)
The following tiered service-credit scheme is a post-beta target only. It is not offered during beta and creates no entitlement today; it is published so you can see where we intend to take the SLA once StorkHost leaves beta. If and when it becomes operative, it would work roughly as follows:
| Monthly control-plane availability | Service credit (post-beta target) |
|---|---|
| 99.0% – < 99.5% | 5% of the affected period's spend |
| 95.0% – < 99.0% | 10% of the affected period's spend |
| < 95.0% | 25% of the affected period's spend |
- Cap: credit would be computed against the run cost of the affected workloads over the affected period and capped at that period's spend for those workloads. You could never be credited more than you spent running the thing that went down.
- Form: credits would be added to your prepaid balance, have no cash value, and not be redeemable for fiat.
- To claim (post-beta): notify us at
support@storkhost.cloudwithin 30 days of the incident, identifying the affected workloads and time window. We would verify against our metering ledger and status-page record.