What our SLA actually covers (and what counts as scheduled maintenance)

The LYLIX Service Level Agreement (SLA) lives in the legal section; this article translates the relevant pieces into practical "what-this-means-for-you" language. Covers what's guaranteed, what counts as downtime, what doesn't, how to claim a credit, and the common gotchas.

The headline numbers

• 99.9% network uptime per month. Roughly 43 minutes of unscheduled downtime per month before SLA credits start to apply.
• 5% of monthly fees credited per 60 minutes of unscheduled network downtime.
• Cap: 100% of monthly fees for the affected service. We're not refunding more than you paid.
• Same terms apply to hardware availability (CPU / RAM / disk / network resources). Inability to use the plan you paid for counts the same way.

What counts as covered downtime

• Network outages affecting your VPS's reachability from the public internet (carrier issue, datacenter network failure).
• Hypervisor failures that take your VPS offline (host crash, storage subsystem failure on the host).
• Resource availability failures (host is so overloaded your VPS can't get the CPU/RAM you paid for).

What does NOT count as covered downtime

Per the SLA, these are explicitly excluded:

• Scheduled maintenance. We announce in advance via the customer-portal Announcements feed plus email, generally 24+ hours ahead. Maintenance windows don't count against SLA.
• Emergency maintenance. Sometimes preventative or security work has to happen without notice. Also doesn't count.
• Software running inside your VPS. If your nginx crashed, your application leaked memory, your kernel panicked because of a customer-installed driver — those are guest-side issues; SLA covers the host, not the guest.
• Anything you broke yourself. Misconfigured firewall locked you out, bad kernel upgrade, rm -rf / — not covered.
• Force majeure. Major DDoS, carrier outage upstream of the datacenter, natural disasters.
• Legal action requiring service interruption (court order to suspend a service, etc.).

Scheduled maintenance — how it's communicated

Two channels, both mandatory for you to monitor:

1. Customer portal → Announcements. New announcements appear on your dashboard automatically.
2. Email to the address on your account. Make sure the address you have on file is one you check (or set up a Contact under Account → Contacts with announcement permission for an alternate email).

If you missed an announcement and were caught off-guard by scheduled maintenance, the SLA doesn't help — the work was scheduled, even if you didn't see the notice. Worth checking the Announcements feed periodically.

How to claim a credit

Per the SLA, claims must be filed within 5 business days of the outage via a Billing ticket. Include:

• The service ID affected (your service number in the portal).
• The date and time range of the outage.
• Logs or external monitoring evidence if you have any (Uptime Robot, your own external check).
• Brief description of what wasn't working.

We review against our internal monitoring and event logs and either grant the credit (applied to your account, used on the next invoice) or explain why the period doesn't qualify. Typically resolved within 48 hours; can take up to 7 days for complex cases.

SLA credits are account credits, not refunds

Credits apply to your next invoice. They don't get refunded to your card. If your credit balance exceeds your next invoice, the remainder carries forward.

If you cancel your service while holding unused credit, the credit doesn't convert to cash — it expires at cancellation. If you need a true refund instead, open a billing ticket and we'll discuss case-by-case.

Customers in arrears don't qualify

If you have an unpaid invoice when the outage occurs, you can't claim SLA credit for the outage period. Pay current first, then claim. This is in the SLA explicitly.

Customers violating the Acceptable Use Policy (sending spam, hosting malware, running illegal services) also don't qualify — the SLA exists for legitimate customers in good standing.

Why we don't publish "1-hour response SLA" promises

We're a small team. We aim for fast response — for service issues, the typical pattern is acknowledgment within an hour business-hours and we keep you posted through resolution. After- hours emergencies are covered but slower than business hours.

We deliberately don't publish a contractual response-time SLA because we won't hit "1 hour, 100% of the time, 24/7" honestly. Better to underpromise than overpromise.

If you need a host with hard contractual response times, you need a much larger operator — we're optimized for actual reachable engineers rather than tier-1 ticket triage queues.

What you can do to maximize uptime

The SLA covers our obligations. Your half of the equation is keeping the guest OS, your applications, and your configuration healthy. Things that help:

• Snapshot before risky changes so you can revert in 30 seconds instead of opening a ticket. See snapshot article.
• External monitoring (Uptime Robot, Pingdom, StatusCake) so you know about an outage at the same time we do. Faster acknowledgment, more accurate downtime timestamps for any SLA claim.
• Off-host backups so a worst-case "we lost the storage" event doesn't end your business. See off-host backups.
• Watch the Announcements feed so you're not surprised by scheduled maintenance.
• Keep your account email current so service notifications reach you.

A note on the SLA philosophy

The SLA exists primarily to make the financial relationship clear, not to be a primary tool for customer satisfaction. Most of the time you'll never invoke it — service runs, you don't think about it. If something goes wrong, the SLA defines the remedy in contractual terms; the friendly resolution (an extra month free because we genuinely failed you, a credit applied without you even asking) sometimes happens too, depending on circumstances.

If you ever feel an outage wasn't handled fairly, escalate through a ticket — we'd rather know than have you quietly disappointed.