Quick answer: The Cloud2Y SLA covers what the platform is responsible for: network availability, power and the physical hardware your service runs on. It does not cover your OS, applications or data. Concrete availability figures and any compensation terms are defined in the official Terms of Service / order agreement — confirm the current numbers via support before relying on them.
Overview
An SLA (Service Level Agreement) draws the line between provider responsibility and customer responsibility. For unmanaged infrastructure the split is simple: Cloud2Y keeps the data centre, network and host hardware running; everything inside your server — OS, software, security, backups — is yours to operate. The Cisco-based network across Kyiv (DC2), Lviv (DC3), Amsterdam and Singapore is built with redundancy so that single failures do not take customers down.
Before you start
- Read the SLA/ToS text at order time — that is the binding document; this article is orientation.
- Dedicated servers have their own support-scope specifics — see dedicated server SLA and support scope.
- Plan your own layer: monitoring, backups and security are not covered by any infrastructure SLA.
Step-by-step guide
What the SLA practically covers and how to use it:
- Network: reachability of your server's uplink — packet loss or outages on the Cloud2Y side are SLA territory; report them with MTR data.
- Hardware: failed host components (disk, PSU, NIC) are diagnosed and replaced by Cloud2Y — see the replacement policy.
- Power and facility: data-centre power and cooling redundancy is the provider's job.
- Exclusions: problems inside your OS, application crashes, misconfiguration, compromise and announced maintenance windows are not SLA incidents.
- Claims: if you believe an SLA-relevant outage occurred, open a ticket with timestamps and evidence; the team verifies against monitoring.
Common issues
- "My site is down" ≠ SLA incident: most downtime is application-level; check your stack first, then escalate with data.
- Maintenance confusion: planned windows announced in advance are excluded — see maintenance notifications.
- Assuming numbers: do not rely on an uptime percentage you read elsewhere — get the current figure from the ToS or support.
When to contact support
Open a ticket to report suspected platform-side outages (attach times and traceroutes), to request the current SLA text, or to ask whether a specific incident qualifies.
Frequently asked questions
What does the Cloud2Y SLA actually cover?
The infrastructure side: network availability, data-centre power and the physical host hardware. Your operating system, applications, data and backups are outside any infrastructure SLA.
Where do I find the exact uptime percentage?
In the official Terms of Service or by asking support. This explainer deliberately avoids quoting numbers so outdated copies never contradict the binding document.
How do I report an outage as an SLA incident?
Open a ticket with timestamps, your service details and evidence such as MTR reports both directions. The team verifies the event against platform monitoring and answers on eligibility.
Related articles
- Dedicated server SLA and support scope
- Support scope: managed vs unmanaged services
- Planned maintenance policy
- Dedicated server replacement policy
Need a hand? Contact Cloud2Y support →
