Service level, Rogue Wave Hosting

This page is the shared vocabulary for availability at Rogue Wave Hosting. It defines what unavailability means, separates it from slowness, lists what falls outside it, and sets out how to report and escalate an incident so that it reaches the right place quickly.

Read section 10 before you read anything else if what you need is the numeric commitment: this page deliberately does not assert one, and section 10 explains where it lives instead.

1. What this page covers

It applies to the parts of the service we operate: the host hardware your instance runs on, the virtualisation layer, the storage backing your disk, the network inside the region you chose, the routing of your dedicated IPv4 address, and the provisioning and control functions of the client portal.

It does not apply to anything inside your instance. The service is unmanaged and you hold full root or administrator access, which means your operating system, your services, your firewall rules and your application code are outside the boundary this page measures. Section 5 makes that concrete.

It is part of the terms of service and uses the same definitions.

2. Unavailability

An instance is unavailable when a fault in the parts of the service we operate makes it unreachable or unusable. In practice that means one of the following, and in each case the cause sits on our side of the boundary in section 1:

The host your instance runs on has failed or is powered off, so the instance is not running and cannot be started.
The instance is running but there is no network path to its dedicated IPv4 address from outside our network, and the loss of that path is caused by our network rather than by your firewall or routing.
The storage backing your disk is unavailable or is failing reads and writes at the platform level, so the operating system cannot function.
The virtualisation layer has stopped presenting your allocated vCPU, memory or disk to the instance.
A control function is unavailable, meaning the client portal cannot start, stop or rebuild an instance. This is treated separately from the instance itself: a portal fault while your server keeps serving traffic is a control-plane incident, not an instance outage.

Unavailability is a binary state for a given instance, and it is measured per instance rather than per account. If you run three instances and one host fails, one instance was unavailable.

3. Degraded performance

Degraded performance is when the instance is reachable and running but is slower or less consistent than it should be. It is a real problem and we want to hear about it, but it is a different category from unavailability and is handled differently.

Typical cases:

Disk latency or throughput below what the NVMe storage would normally deliver, while reads and writes still complete.
Elevated packet loss or latency on a path that is still carrying traffic.
A workload that has outgrown the memory on your plan and is swapping, or one that is saturating its own dedicated vCPU.
Throughput reduced while DDoS mitigation is active against an attack aimed at your address.

The first two are ours to investigate. The third is a capacity question, and the fix is usually an upgrade: memory and disk are expandable, upgrades are prorated and no rebuild is required. The fourth is mitigation working as intended, and section 7 covers it.

Note that a benchmark figure such as a base clock or a single-core score describes the hardware, not a guaranteed throughput for your particular workload. A score that does not reproduce on your application is not in itself degraded performance.

4. How an incident is measured

An incident starts at the earlier of the time our own monitoring records the fault and the time you open a ticket that we confirm as unavailability.
It ends when the instance is reachable and usable again at the platform level. If your operating system then needs to finish booting, run a filesystem check or start your own services, that time is yours rather than ours.
Duration is the time between those two points, excluding any period covered by section 5.
Where our records and yours disagree, both are looked at. Platform-side logs and mitigation records are what we can verify directly, so send your own monitoring data with the report and we will reconcile the two.

Reporting the incident promptly matters for this reason: a short outage reported days later is much harder to attribute than one reported while it is happening.

5. Exclusions

The following are not unavailability, and time attributable to them is not counted as such:

Scheduled maintenance carried out in line with section 6, and emergency maintenance needed to address a security or stability problem.
Anything you configured inside your instance. A crashed or misconfigured service, a full disk, a kernel or driver you installed, a failed package upgrade, an operating system that will not boot after your change, resource exhaustion inside the instance, or an expired certificate on your own application.
Firewall and network configuration you control. Blocking your own port, blocking ICMP and then concluding the server is down, locking yourself out of remote access, changing the instance network configuration, or losing access because you rotated a key. You open your own ports through the firewall on your VPS, and a closed port is not an outage.
Suspension. Time during which an instance or account is suspended for non-payment or for a breach of the acceptable use policy, including a suspension applied to stop ongoing harm from a compromised instance.
Your own request. A reboot, reinstall, region change or power-off you asked for or initiated, and any downtime that follows from a change you made in the portal.
Upstream and third-party network events. Faults in networks beyond ours, including transit and peering partners, internet exchanges, your own access network, and routing problems originating elsewhere on the internet. We will work with the operator concerned, but a path we do not run is outside what this page measures.
Third-party services you depend on. External DNS, a content delivery network, an external database or payment provider, or a software repository your deployment pulls from.
Attack traffic aimed at you. Throughput reduction while DDoS mitigation is active, and the effect of an attack sourced from or against your own application at a layer mitigation does not cover.
Force majeure. Events outside our reasonable control, including natural events, fire, flood, war, civil unrest, labour action, utility failure at a facility, government action, and orders from a competent authority.

6. Maintenance

Hardware and the software that runs it need work done on them from time to time. Where maintenance is planned and will interrupt your instance, we give notice to the email address on your account with the window and the expected impact, and we schedule disruptive work outside regional business hours where that is practical.

Much of what we do is not disruptive at all and you will not be notified about it: capacity added to a region, network changes that do not move traffic off your path, and updates to the provisioning system.

Emergency maintenance is different. Where a vulnerability, a failing component or a stability problem needs immediate action, we act first and notify as soon as we reasonably can. A host that is about to fail is better rebooted on our schedule than on its own.

7. DDoS protection

DDoS protection is included on every plan at no extra cost, in every region, and it is not an add-on you have to enable. Mitigation is automatic: attack traffic aimed at your dedicated IPv4 address is detected and filtered without you opening a ticket and without you doing anything to your instance.

Two things follow from how mitigation works:

While mitigation is active, throughput to your address can be lower than normal and some legitimate traffic can be affected by filtering. That is the trade being made, and it is degraded performance under section 3 rather than unavailability.
Mitigation operates on network traffic. It does not protect against abuse at the application layer, against a vulnerability in your own software, or against traffic you have invited through your own firewall. Rate limiting and application-level defences inside the instance remain yours.

If you believe an attack is affecting your instance and mitigation has not engaged, report it as an incident under section 8 and say that you suspect an attack, so it is routed as one.

8. Reporting a suspected outage

Report suspected unavailability or degraded performance to support@roguewavehosting.com, or open a ticket from the client portal if the portal itself is reachable. Report it as it happens rather than afterwards.

Include as much of this as you have:

The instance, its region, and its dedicated IPv4 address.
When the problem started, with the time zone stated, and whether it is ongoing or has recovered.
What you observe: unreachable entirely, reachable but not serving, slow, or intermittent.
Evidence from outside the instance. A traceroute or MTR from a network that is not yours, with the output in both directions if you can get it, plus ping results and whether the address responds on any port at all.
What you have already ruled out inside the instance: whether the operating system is up, whether your services are running, whether the disk is full, and whether you changed the firewall or any configuration recently.
For degraded performance, a measurement rather than an impression. Disk read and write figures, packet loss over a stated interval, or request latency from your own monitoring.
Any relevant output from your own monitoring or graphs.

Two checks before you send it will save a round trip: confirm the problem from a network other than your own, and confirm the instance is powered on in the client portal.

9. Escalation

Open a ticket. Everything starts here, because the ticket is what carries the diagnostic detail and creates the record of when the incident was reported.
Ask for escalation in the ticket. Reply to the existing thread and say that you are escalating, rather than opening a second ticket. A duplicate splits the history and slows the response. State the business impact: an instance serving production traffic is triaged differently from one that is idle.
Add new evidence as you get it. A change in symptoms, a recovery, or a recurrence are all worth adding to the same thread.
Keep the ticket open until you agree it is resolved. Where we believe an incident is over and you do not, say so in the thread and it stays open.

Where an incident affects more than one customer in a region, we may consolidate updates and post them to the ticket rather than sending separate diagnoses. Ask in the ticket for a written summary after a significant incident and we will provide one.

10. Availability commitments and remedies

This page defines unavailability and its exclusions. It does not state a numeric availability percentage, and it does not set out a credit schedule, because those are commercial terms rather than definitions.

Any numeric availability commitment that applies to you, and any remedy attached to it, is set out in your order at the time of purchase. Where your order contains one, the definitions and exclusions on this page are what that commitment is measured against, and the remedy in your order is the remedy for a breach of it. Where your order does not contain one, there is no numeric commitment in force and none should be inferred from this page, from the marketing pages, or from any figure quoted in conversation.

We would rather say that clearly than publish a number we have not committed to. If you need an availability commitment written into your order, ask before you buy: write to support@roguewavehosting.com with the configuration and region you have in mind.

11. Data and recovery

Restoring your data is not part of incident handling, because Rogue Wave Hosting does not provide a backup or snapshot service. If a host or a disk fails, what we restore is the availability of the platform, not the contents of your instance.

Keep your own copies, keep them off the instance they protect, and test that you can restore from them. Section 10 of the terms of service covers this allocation of responsibility in full.

12. Contact

Incidents, escalation and questions about this page: support@roguewavehosting.com
Attack or abuse traffic originating from our network: abuse@roguewavehosting.com
Privacy and data protection requests: privacy@roguewavehosting.com

Related pages: terms of service, acceptable use policy and privacy policy.