Service Level Agreement

1. Scope

This Service Level Agreement ("SLA") is incorporated by reference into the Terms of Service and governs the service-level commitments we make to customers using the Services described below.

1.1 Covered Services

This SLA applies to the following Service categories:

• Virtual private servers (VPS), including all Linux KVM tiers
• Remote Desktop Protocol servers (RDP)
• Dedicated servers (DS)
• GPU servers (GPU)
• Storage and backup servers
• Streaming servers
• Game servers

1.2 Services with adjusted commitments

Shared and cPanel hosting carry the uptime commitments in Section 2 but with measurement adjusted for the shared-tier architecture (the relevant measurement target is the shared host availability rather than per-customer container availability).

1.3 Services not covered

Email and SMTP hosting carry separate availability commitments published on their respective product pages. Beta and preview Services explicitly labelled as such are not covered by this SLA.

2. Uptime Commitment

2.1 Standard plans

Standard plans — VPS-1 through VPS-8, RDP-Basic and RDP-Pro, all Storage tiers, Game-S and Game-M, Streaming-1 — carry a monthly uptime commitment of 99.9%.

A 99.9% monthly uptime corresponds to a maximum of 43 minutes 50 seconds of downtime in a 30-day calendar month, or 44 minutes 38 seconds in a 31-day month.

2.2 Pro, Premium, Dedicated, GPU plans

Higher-tier plans — VPS-16, RDP-Power, all Dedicated tiers (DS-Lite through DS-Beast), all GPU tiers (GPU-Lite through GPU-Beast), Game-L, Streaming-2 — carry a monthly uptime commitment of 99.99%.

A 99.99% monthly uptime corresponds to a maximum of 4 minutes 23 seconds of downtime in a 30-day calendar month, or 4 minutes 28 seconds in a 31-day month.

3. Measurement Methodology

3.1 External monitoring

Uptime is measured by external monitoring nodes operated by third-party uptime providers (UptimeRobot, Better Uptime, or equivalent). We currently maintain three (3) independent monitoring nodes located in geographically distinct regions to avoid single-point-of-failure measurement.

3.2 Probe interval

Each monitoring node probes each Service's primary endpoint every five (5) minutes.

3.3 Majority-rules detection

Downtime is recorded when at least two of the three monitoring nodes report the Service as unreachable in the same probe window. This avoids attributing local network outages at the monitoring node to a SilentHosts incident.

3.4 Downtime accrual

A "downtime minute" is any whole minute during which majority-rules detection is in the unreachable state. Partial minutes are rounded up to whole minutes for credit-calculation purposes.

3.5 Customer-side measurement

Customers may use their own monitoring infrastructure to corroborate downtime claims. Where customer-side measurement diverges materially from our monitoring, we will share our measurement data and work toward agreement on the actual downtime period.

4. Service Credits

4.1 Credit tiers

If a covered Service falls below its monthly uptime commitment, the customer is entitled to a service credit calculated as a percentage of the monthly fee for the affected Service:

4.2 Application

Service credits are applied to the next invoice of the affected Service. If the customer terminates the affected Service before the next invoice, the credit is paid out as a refund in the original payment method, subject to processing terms in the Refund Policy.

4.3 Cap

The total credit for any affected Service in any single month cannot exceed 100% of that Service's monthly fee. Service credits are the customer's sole and exclusive remedy for any failure to meet uptime commitments under this SLA.

5. Exclusions

The following do not count as downtime for the purposes of Section 2:

5.1 Planned maintenance

Maintenance announced at least forty-eight (48) hours in advance through the customer panel and the status page at /status. Routine maintenance windows are typically scheduled during off-peak hours for the relevant jurisdiction.

5.2 Force majeure

Acts of God, natural disasters, war, civil unrest, government action, terrorism, or comparable events outside our reasonable control.

5.3 Customer fault

Downtime caused by customer misconfiguration, customer-controlled software bugs, exceeding plan resource allocations, or operations performed by the customer (such as voluntary reboot, OS reinstall, or configuration change that disables remote access).

5.4 Third-party network outages

Downtime caused by third-party network outages outside our network and outside our peering agreements, including outages of the customer's own ISP, transit provider, or last-mile network.

5.5 AUP-related action

Suspension under the AUP does not count as downtime. Disputed AUP suspensions reversed on appeal are not retroactively counted as downtime; the customer's remedy in that case is documented in the AUP.

6. Network Performance

6.1 Latency targets

We commit to median latency targets between our edge network and the major regional internet exchanges, measured monthly:

6.2 Packet loss

We commit to less than 0.1% packet loss on intra-datacenter traffic measured over any rolling 5-minute window, excluding intervals affected by active DDoS scrubbing.

6.3 Throughput

We commit to throughput at the port speed configured on the Service, less the typical encapsulation and transit overhead. Sustained throughput materially below port speed (after excluding transit congestion outside our network) is treated as a network performance miss.

7. DDoS Mitigation Timing

7.1 Volumetric attacks

Volumetric DDoS attacks targeting customer Services are detected and tagged by our anycast scrubbing edge within sixty (60) seconds of attack onset. Mitigation is automatic and does not require customer action.

7.2 Application-layer attacks

Application-layer (L7) attacks require application-specific rules. We provide standard rules at the edge for common patterns; rules tailored to the customer's specific application (URL paths, request signatures) are the customer's responsibility, optionally configurable through Cloudflare or BunnyCDN at the application edge.

7.3 Capacity per plan tier

Volumetric scrubbing capacity scales with plan tier and is documented at /features/ddos-protection. Sustained attacks above the plan's scrubbing capacity may trigger an upgrade conversation rather than a service credit.

8. Provisioning SLA

8.1 KVM-based Services

KVM VPS, RDP, shared, and cPanel plans complete provisioning within five (5) minutes of payment confirmation. Confirmation is the moment the cryptocurrency payment reaches the threshold confirmations described on the relevant payment-method page; for card payments where supported, confirmation is settlement at the processor.

8.2 Dedicated and GPU

Stock dedicated and GPU plans complete provisioning within twenty-four (24) hours of payment confirmation. Custom dedicated builds (multi-GPU, exotic RAID configurations, specific NIC models) are flagged at order placement and may take 1–3 business days.

8.3 Bulk orders

Bulk orders (more than five Services in a single transaction) require coordination with the sales team. Lead times are agreed at order placement and form part of the order-specific SLA.

8.4 Provisioning miss credits

If provisioning exceeds the relevant target by more than 25%, the customer is entitled to a one-month service credit on the affected Service. This is in addition to any uptime-related credit accruing under Section 4.

9. Support Response Times

9.1 Severity definitions

• Critical: server down, data inaccessible, security incident in progress
• High: degraded performance, partial outage, intermittent unreachability
• Normal: configuration question, feature inquiry, billing clarification not affecting service operation
• Low: documentation feedback, process question, non-time-sensitive request

9.2 Response targets

9.3 Support channels

Tickets are accepted through the customer panel and via email to support@silenthosts.io. The 24/7 chat (where available, lazy-loaded per the documentation in /features) is for general inquiries; severity-Critical issues should always also be opened as tickets to ensure tracking.

10. How to Claim Credits

10.1 Claim window

Service credits must be claimed within thirty (30) days of the incident giving rise to the credit. Credits not claimed within this window are forfeited.

10.2 Claim procedure

To claim a credit, send an email to support@silenthosts.io with the following information:

• Account email and affected Service identifier
• Date and time of the incident in UTC
• Reason for the claim (uptime miss, provisioning miss, network performance miss)
• Any external monitoring data the customer has corroborating the incident

10.3 Processing

We acknowledge claims within forty-eight (48) hours. Substantive resolution typically completes within seven (7) business days. Approved credits are applied to the next invoice or, on customer request, paid out as a refund per Section 4.2.

11. Maintenance Windows

Maintenance advisories are published on the status page at /status and emailed to all affected customers. The standard advisory window is forty-eight (48) hours. Emergency maintenance — required to address an active security or stability issue — may be performed without prior advisory; in that case, a post-mortem is published at the status page within five (5) business days.

12. Modifications to This SLA

We may update this SLA periodically. Material changes that reduce the level of service guaranteed under this SLA require thirty (30) days' notice through the procedure in Terms of Service Section 15. Changes that improve commitments or clarify language take effect immediately on publication. The "Last updated" date at the top of this document reflects the most recent change.