[$ ] legal: sla

1. Scope

This SLA applies to every active Service the operator supplies under the XMRHost brand. It is incorporated into the Terms of Service (/legal/tos) by reference. Where this SLA conflicts with the Terms, the Terms prevail; where this SLA is silent, the Terms apply by default.

The SLA is a commercial commitment, not a representation of the underlying technology’s capability. The operator has selected upstream providers, hardware tiers, and network topologies designed to support the commitments below; the SLA is the operator’s contractual undertaking that those design choices in fact produce the committed availability and response times. Where the operator falls short, the credit-ladder in §4 below is the Customer’s exclusive remedy under this SLA (the broader liability framework is at TOS §9).

2. Definitions

• Available — the Service-instance is reachable from the operator’s external monitoring stack (located outside the Operating Jurisdiction’s primary AS) on the documented service-port for that Service tier. For VPS / dedicated / GPU tiers: ICMP echo + TCP-22 (or the customer-configured SSH port) reachability with sub-2000ms RTT. For tor-hidden-service / i2p-node / lokinet-exit tiers: protocol-specific liveness (descriptor publication for Tor; floodfill participation for I2P; service-node reachability for Lokinet).
• Unavailable — not Available, sustained for at least 60 consecutive seconds, confirmed from at least two independent monitoring vantages.
• Downtime — the cumulative wall-clock duration over a calendar month during which the Service-instance is Unavailable, after subtracting any Excluded Periods (§5).
• Monthly Uptime Percentage (MUP) — (total minutes in month – Downtime minutes) / total minutes in month, expressed as a percentage to four decimal places.
• Service Credit — a percentage of the Customer’s invoice for the affected calendar month, applied as a credit against the Customer’s next invoice or refunded in XMR per /legal/refund mechanics if the Customer’s Service is terminated before the next invoice falls due.
• Severity Tier — the operator’s classification of an incident (S0 / S1 / S2 / S3) per the matrix in §6 below, driving the operator’s response-time commitment.

3. Uptime commitment by tier

The operator commits to the following Monthly Uptime Percentage per Service tier:

Service tier	Committed MUP	Permitted Downtime per month
vps-* (shared-tenancy VPS)	99.9%	up to 43 minutes 49 seconds
ds-* (dedicated server)	99.95%	up to 21 minutes 54 seconds
gpu-* (GPU server)	99.9%	up to 43 minutes 49 seconds
tor-* (Tor hidden service)	99.5% (descriptor publication)	up to 3 hours 39 minutes
i2p-* (I2P node)	99.0% (floodfill participation)	up to 7 hours 18 minutes
lokinet-* (Lokinet exit node)	99.5% (service-node reachability)	up to 3 hours 39 minutes

The relaxed commitments on the privacy-network tiers reflect the upstream protocol’s tolerance for transient unreachability — Tor descriptor republication, I2P floodfill churn, and Lokinet’s staked-node rotation are baseline-noisy on a sub-hour timescale, and the committed MUP is calibrated against the protocol’s normal operating envelope rather than a hypothetical hard-availability ceiling.

4. Credit ladder

If the Monthly Uptime Percentage for a Service-instance falls below the committed MUP for the relevant tier, the Customer is entitled to the Service Credit set out below, claimed per §7.

4.1. VPS / Dedicated / GPU credit ladder

MUP	Service Credit
≥ committed MUP	0% (no credit)
≥ 99.0% but < committed	10% of monthly invoice
≥ 95.0% but < 99.0%	25% of monthly invoice
≥ 90.0% but < 95.0%	50% of monthly invoice
< 90.0%	100% of monthly invoice

4.2. Tor / I2P / Lokinet credit ladder

MUP	Service Credit
≥ committed MUP	0% (no credit)
≥ 95.0% but < committed	10% of monthly invoice
≥ 90.0% but < 95.0%	25% of monthly invoice
≥ 80.0% but < 90.0%	50% of monthly invoice
< 80.0%	100% of monthly invoice

The Service Credit is the Customer’s exclusive remedy under this SLA for the breach. It does not duplicate, nor is it duplicated by, any remedy under the TOS for material breach.

5. Excluded Periods

The following are excluded from the Downtime calculation in §2 above:

5.1. Scheduled maintenance

Operator-scheduled maintenance windows announced at least 72 hours in advance via the registered Account email and via the operator’s status surface (forthcoming under /uptime; the page does not exist at MVP). Scheduled maintenance is capped at 4 hours per Service-instance per calendar month and is generally scheduled in the local-Operating-Jurisdiction off-peak window (02:00–06:00 in the local timezone of the upstream datacenter).

5.2. Force majeure

Unavailability caused by an event beyond the operator’s reasonable control, as defined in TOS §10. The cap-and-carve-outs in TOS §10 apply.

5.3. Customer-side misconfiguration

Unavailability caused by the Customer’s own configuration of the Service-instance (e.g. firewalled own-monitoring port, broken sshd_config blocking the operator’s reachability checks, kernel panic from a Customer-applied patch). Where the misconfiguration is identifiable from the operator’s monitoring data, the operator records the basis and excludes the affected duration. The Customer may contest the exclusion via the support mailbox under §8.

5.4. Customer suspension

Unavailability resulting from suspension of the Service under TOS §7 (non-payment, AUP violation, legal compulsion). Service Credit accrues only against the operator’s commitment to keep an active, paid-for, AUP-compliant Service-instance reachable.

5.5. Network paths outside the operator’s control

Unavailability caused by routing failures, BGP instability, or transit-provider failure on the Customer’s egress path between the Customer’s monitoring origin and the operator’s edge — i.e. last-mile / ISP-side issues affecting the Customer’s perception of availability but not the operator’s actual delivery. The operator’s external monitoring stack is the canonical Availability oracle; Customer-side monitoring is informational only.

6. Severity-tier response matrix

Customer-reported incidents are classified by the operator on receipt and entered into the response queue per the table below. The response-time commitment is the time within which the operator acknowledges receipt of the report and begins active investigation; it is NOT a time-to-resolution commitment (which depends on the underlying root-cause and is not contractualised here).

Severity	Description	Response time
S0	Service-instance fully Unavailable, billing-impacting, no Customer-side workaround	30 minutes
S1	Service-instance Available but materially degraded (e.g. > 80% packet loss, > 10× normal latency)	2 hours
S2	Partial degradation, individual feature impaired (e.g. one of multiple IPs Unavailable, snapshot infrastructure down)	8 hours
S3	Operational enquiry, configuration assistance, non-time-critical billing question	2 business days

Response-time commitments apply 24/7 for S0 and S1; S2 commitments apply 24/7 with the 8-hour clock running across off-hours; S3 commitments apply during operator business hours (09:00–18:00 local time of the operator’s primary support team, Monday–Friday excluding the operator’s published holiday schedule).

7. Credit claim procedure

Service Credits are not issued automatically; the Customer must claim them within thirty (30) calendar days of the end of the affected calendar month. The procedure:

1. The Customer submits a credit-claim ticket via the support mailbox listed under /legal DISPATCH, identifying the Service-instance, the affected calendar month, the asserted MUP, and the underlying incidents (the Customer’s own monitoring data is helpful but not required; the operator’s monitoring is the canonical source).
2. The operator acknowledges receipt within the S2 response-time window (8 hours).
3. The operator reviews the claim against its monitoring data and the §5 exclusions and responds within 14 calendar days with either (a) the credit issuance, (b) a request for additional information, or (c) a reasoned rejection.
4. If the Customer disputes the operator’s response, the dispute is processed under TOS §11.

The credit is applied to the Customer’s next invoice. Where the Customer’s Service is terminated before the next invoice falls due, the credit is refunded in XMR per /legal/refund mechanics within fourteen (14) calendar days of the credit being approved.

8. Status surface and incident communication

The operator maintains an external status page (forthcoming under /uptime) reflecting current and recent incidents at the Operating-Jurisdiction level. The status page is the primary communication channel for in-progress incidents; per-Customer email is dispatched for S0 and S1 incidents that affect the Customer’s specific Service-instance.

Post-incident root-cause analyses (RCAs) are published on the status page within 14 calendar days of incident resolution for S0 incidents that exceeded the per-tier permitted Downtime, or for any S0 / S1 incident whose duration exceeded 4 hours. Customer-confidential information is excluded from public RCAs; per-Customer RCA detail is available on request to the support mailbox.

9. Carve-outs from this SLA

This SLA does not apply to:

• Trial Services, beta-tier Services, and any Service explicitly designated by the operator as “preview” or “experimental”.
• Services suspended for non-payment, AUP violation, or legal compulsion (per TOS §7).
• Add-on features explicitly offered as best-effort (e.g. the tor-relay-config add-on at MVP — operator-supported but not contractually-committed availability).

10. Updates

This SLA is updated to reflect (a) introduction of new Service tiers (the SLA must be extended before the tier accepts production orders), (b) changes in upstream-provider commitments that materially affect the operator’s ability to honour these terms, or (c) procedural refinements. Material updates are effective on the effectiveFrom date with at least 30 days’ notice; downward revisions to committed MUPs require a 90-day notice window and entitle the Customer to terminate the affected Service for a pro-rata refund per /legal/refund.