Service Level Agreement

What We Commit To

DustBowl.Games commits to 98% monthly uptime for all game server subscriptions, backed by 24/7 automated monitoring. This applies to every paid server hosted on our platform, measured on a calendar-month basis.

We believe in infrastructure transparency. Our servers run on a residential Kubernetes homelab — real hardware, in a real home, connected to a real ISP. This is not a hyperscale cloud provider with redundant data centres across multiple continents. We are a small operation that takes pride in delivering reliable hosting at an honest price, backed by monitoring and automation that punches well above its weight.

Uptime is defined as the game server process being reachable and responsive to player connections. If players cannot connect to or interact with their server due to an issue on our side, that counts as downtime.

How It's Measured

We use Uptime Kuma as our public uptime monitoring dashboard. Every server and critical service is checked automatically, and the results are visible to anyone — no login required.

• Check interval: Every 60 seconds
• Failure threshold: 2 consecutive failed checks before a service is marked as down
• Calculation: Monthly uptime percentage is calculated as:
  (Total minutes in month − Downtime minutes) ÷ Total minutes in month × 100

Only downtime recorded by Uptime Kuma is used for SLA calculations. If it is not on the dashboard, it did not happen as far as the SLA is concerned.

What Counts as Downtime

The following events count toward your server's downtime when they prevent players from connecting or using the service:

• Server process crashes — the game server application crashes or becomes unresponsive
• Infrastructure failures — hardware failures, Kubernetes node outages, storage issues, or other platform-level problems within our control
• Network failures within our control — local network misconfigurations, firewall issues, or routing problems originating from our infrastructure

If we caused it or could have prevented it, it counts.

What Does NOT Count

The following are excluded from downtime calculations:

Scheduled Maintenance

We perform regular maintenance to keep the platform healthy and up to date. All scheduled maintenance follows these rules:

• Advance notice: Announced at least 24 hours in advance on our System Status page and by email
• Standard window: Tuesdays, 2:00 AM – 4:00 AM (local server time)
• Emergency maintenance may occur outside this window but will still be communicated as early as possible

Scheduled maintenance that falls within the announced window and notice period is not counted as downtime for SLA purposes.

SLA Credits

If we fall below our 98% uptime commitment in a given calendar month, you are entitled to SLA credits applied to your next billing cycle. Credits are calculated based on the tier your server's uptime falls into:

• Applied automatically: Credits are calculated and applied to your next invoice without needing to submit a ticket
• Prorated: Credits are prorated based on the affected server's monthly subscription cost
• Credits, not refunds: SLA credits are applied as a discount on future billing — they are not issued as cash refunds
• Forfeited on cancellation: Any outstanding SLA credits are forfeited if you cancel your subscription before they are applied

Monitoring & Support Hours

Our monitoring runs 24/7 — automated health checks watch every server around the clock and alert our team the moment something goes down, day or night. Human support responses are handled during normal EST business hours; outside those hours we respond on a best-effort basis, prioritising critical outages. If you need guaranteed round-the-clock human response backed by a stricter SLA, a dedicated or managed plan is the better fit.

When things go wrong, you deserve to know what is happening. During business hours we follow this communication timeline for unplanned outages (automated detection runs 24/7 regardless):

• First update: Within 15 minutes of the outage being detected, we will post an acknowledgement on our System Status page with what we know so far
• Progress updates: Every 30 minutes until the issue is resolved, we will post an update with current status and estimated time to resolution
• Post-mortem: For any outage lasting longer than 30 minutes, a written post-mortem will be published within 24 hours covering what happened, why it happened, and what we are doing to prevent it in the future

Why 98% and Not 99.9%?

We could slap a 99.9% uptime guarantee on this page like every other hosting company, but we would rather be honest with you.

Our infrastructure is a residential Kubernetes homelab. It is real hardware running in a real home on a residential internet connection. We do not have redundant fibre links, diesel generators, or a network operations centre staffed around the clock.

Here is what those numbers actually mean:

• 99.9% uptime = a maximum of ~44 minutes of downtime per month. One ISP hiccup, one power blip, one bad firmware update — and you have blown past that. For a residential setup, this is unrealistic.
• 98% uptime = up to ~14.5 hours of downtime per month. This gives us an honest buffer for the realities of running on residential infrastructure while still holding ourselves to a meaningful standard.

That said, we consistently aim to exceed 98% by a wide margin. We have real infrastructure, real backups, and real monitoring — automated health checks, self-healing Kubernetes pods, UPS battery backup, and Uptime Kuma watching everything 24/7. We just refuse to promise something we cannot guarantee.

We would rather under-promise and over-deliver than pad a marketing page with numbers that fall apart the first time something goes wrong.