This Service Level Agreement ("SLA") sets out the uptime Xenax Cloud India Private Limited ("Xenax Cloud", "we", "us", "our") commits to, what you get if we fall short, and the other service targets we work to. It forms part of our Terms of Service and governs on questions of uptime and service credits.
The commitment: 99.50% uptime for each calendar month. Below that, you get days added to your service on the scale in Section 5.
Credits are not automatic. You have to claim, within 30 days of the end of the month concerned, Section 7.
This SLA applies to every paid service:
It does not apply to trials, to any service provided free of charge or at a nominal charge, or to a service while it is suspended or terminated. It also does not apply to the availability of our reseller provisioning API, which carries no uptime commitment and no service credit, Section 21.2 of the Terms of Service. Colocation is dealt with in Section 11.
Where a separate signed agreement covers a dedicated or bare-metal server, that agreement's service levels apply instead of this SLA for that service, as Section 23 of the Terms of Service provides.
Terms defined in the Terms of Service have the same meaning here. Where this SLA and Section 15 of the Terms of Service both address a point, this SLA governs, except that where the Terms of Service state a specific commitment that is more favourable to you, that one applies, as Section 1.1 of the Terms of Service provides.
We commit to 99.50% uptime for each calendar month, measured per service.
Uptime is calculated as:
Uptime % = (Total minutes in the month − Downtime minutes) ÷ Total minutes in the month × 100
A 30-day month has 43,200 minutes, so 99.50% allows up to 216 minutes of downtime. The percentage is fixed; the minute figures scale with the length of the month, so February allows proportionately fewer minutes and a 31-day month proportionately more.
Downtime means a period during which your service is not reachable over our network: the host on which your service runs, or the network path to it within our infrastructure, is not responding.
We measure this by ICMP and port reachability checks run against our hosts and network devices from outside our network, using a monitoring service we contract for that purpose, and we correlate what it records against our own hypervisor, network and system logs. Section 12 of the Privacy Policy names the monitoring provider we currently use. That combination, external reachability plus our internal records, is what we can observe and what we can be accountable for.
What we do not measure, and therefore do not commit to. We do not monitor what runs inside your server. On an unmanaged service, the operating system, your applications, databases, web server, firewall rules and configuration are yours, Section 6.1 of the Terms of Service.
If your host is reachable but your website is returning an error, your application has crashed, your disk is full, or your firewall is blocking traffic, that is not downtime under this SLA. We will help you where we can, but it does not generate a credit.
An outage counts only if it lasts 5 consecutive minutes or more. Shorter interruptions, a dropped packet, a single failed check, a routing reconvergence, happen on every network and are not counted.
Downtime runs from the moment our records show the service became unreachable, and ends when reachability is restored. If you open a ticket reporting an outage that our monitoring did not capture, that ticket starts an investigation, and where our system and network logs confirm the outage we count it from the time you reported it.
The following are excluded from the downtime calculation and do not qualify for credits:
| Monthly uptime achieved | Downtime in a 30-day month | Credit |
|---|---|---|
| 99.50% or above | Up to 216 minutes | No credit |
| 99.00% up to but not including 99.50% | More than 216, up to 432 minutes | 1 day added to the service |
| 97.50% up to but not including 99.00% | More than 432, up to 1,080 minutes | 3 days added to the service |
| 95.00% up to but not including 97.50% | More than 1,080, up to 2,160 minutes | 5 days added to the service |
| Below 95.00% | More than 2,160 minutes | 7 days added to the service |
The percentage bands are what govern. The minute column is shown for a 30-day month and is there to make the bands concrete; in a month of a different length the same percentages apply to a proportionately different number of minutes.
A service credit under this SLA is not the same thing as account credit arising from a refund. Section 12 of the Refund Policy explains the difference, refund credit does not expire; the 12-month life above applies only to an SLA credit that could not be applied to a service.
Credits are not automatic. You must notify us by raising a ticket to our Billing department within 30 days of the end of the calendar month in which the downtime occurred. This is a notification requirement so that we can investigate while the logs and evidence are still fresh; if you notify us later we may not be able to verify the outage, and we may decline the claim on that ground. It does not shorten any period allowed to you by the Limitation Act, 1963.
Include:
Downtime is determined by our monitoring records read together with our own hypervisor, network and system logs, and that determination is final for the purposes of this SLA. We will tell you what those records show for the period you have claimed and the arithmetic we applied, and on request we will provide the underlying monitoring data for the period you claimed so that you can verify it independently.
You may also submit your own monitoring reports, UptimeRobot, Pingdom, StatusCake or similar, and we will look at them. They do not by themselves establish a claim, because a single external probe records the whole path between itself and your service, most of which lies outside our network; an outage it records is frequently a fault in transit or peering rather than in your service. Where your report and ours disagree, we investigate the difference rather than dismiss it, and where your evidence shows an outage our own records missed, we will accept it.
Nothing in this Section affects your statutory rights, or your right to escalate to our Grievance Officer under Section 31 of the Terms of Service.
You can claim for a month even if the service has since been cancelled or terminated, as long as you claim within the 30 days.
Planned maintenance is notified in advance. Emergency maintenance: urgent security patching, hardware failure, or anything needed to protect the platform, may be carried out without prior notice, and we publish information about it as soon as we reasonably can.
Both are excluded from the uptime calculation. We publish maintenance and incident information through:
Section 16 of the Terms of Service governs notices generally, including the rule that a notice sent to your registered email address is deemed received.
These are targets, not credit-bearing commitments. We publish them because you are entitled to know what we are working to, and because a target we miss is something you can hold us to and escalate. But missing one does not generate a service credit, only the uptime commitment in Section 2 does.
On dedicated and bare-metal servers, where a component fails and we hold a suitable spare, we target replacement within 8 hours of our confirming the fault. Where a part has to be sourced, we will tell you the expected timeline as soon as we know it.
This covers hardware we own and supply. It does not cover customer-owned hardware, and it does not cover a fault caused by your own configuration or software.
We accept tickets 24 hours a day, every day. Our first-response targets:
| Priority | What it means | First response |
|---|---|---|
| Critical | A service is completely unreachable, a network-wide problem, or a security incident or active compromise | 8 hours |
| Standard | Everything else, including configuration help, partial or intermittent problems, billing, sales and general queries | 24 hours |
"First response" means a human reply that engages with your issue, not an automated acknowledgement. Resolution time depends on what the problem turns out to be and is not something we can promise in advance.
We target packet loss below 1% as a monthly average within our own network: between our edge and the host your service runs on.
We do not set a latency target, and we do not set any target for performance beyond our network. Latency depends on your location, your internet provider, and every network between you and us, none of which we operate. During denial-of-service mitigation, latency rises and throughput may fall because traffic is routed through our scrubbing partner, and Section 4 excludes that from this SLA.
The targets in Section 9 are commercial commitments about ordinary support. They have nothing to do with the deadlines we are legally required to meet for abuse reports, unlawful content and law-enforcement orders, which are shorter, run around the clock, and are not affected by anything in this SLA.
| Obligation | Deadline |
|---|---|
| Content in the nature of non-consensual intimate imagery, nudity, a sexual act, or impersonation including morphed or artificially generated images | 2 hours |
| Order of a competent Indian court, or notification by an appropriate government agency | 3 hours |
| Reporting a qualifying cyber security incident to CERT-In | 6 hours |
| Acknowledgement of any complaint | 24 hours |
| Request to remove content falling within Rule 3(1)(b) of the IT Rules, 2021 | 36 hours |
| Resolution of a general complaint | 7 days |
These come from the Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021 as amended with effect from 20 February 2026, and from the CERT-In Directions dated 28 April 2022. The Copyright, DMCA and Abuse Policy sets them out in full. Reports of that kind should go to abuse@xenaxcloud.com, not through ordinary support.
Colocation is provided under a separate written agreement, and its service levels are set out there rather than in this SLA. That agreement typically covers power, cooling, network connectivity and IP addresses provided by us.
The following are outside any colocation service level: hardware you own and install yourself, and IP address space you bring with you rather than take from us. We do not control the routing, reputation or registry status of address space that is not ours.
We may update this SLA. Material changes, including any reduction in the uptime commitment or the credit scale, are notified at least 15 days before they take effect, by email and through the client area, as Section 30 of the Terms of Service requires. A change does not affect a credit claim already submitted, or a month that has already ended.
| Credit claims and billing | billing@xenaxcloud.com |
|---|---|
| Technical support | support@xenaxcloud.com |
| Abuse and legal orders | abuse@xenaxcloud.com |
| Grievance Officer and escalation | Mr. Sanket Tripathi, grievance@xenaxcloud.com |
| Status page | status.xenaxcloud.com |
| Postal address | Xenax Cloud India Private Limited, H. No. 17, Jyoti Nagar, Fatehpur Road, Banda - 210001, Uttar Pradesh, India |
We use analytics cookies to understand how the site is used so we can improve it. These load only if you accept. The cookie that keeps your session working is always on and needs no consent. Read our Privacy Policy.
