What uptime does DataDack Cloud guarantee?

DataDack Cloud commits to 99.9% monthly uptime for each running virtual machine, measured per instance and, for multi-AZ deployments, at the region level. Block storage, VPC networking, static IPs and load balancers carry a 99.95% commitment, and the console and public API carry 99.5%. Missing a commitment entitles you to a service credit of 10%, 30% or 100% of that resource's monthly charges depending on the size of the shortfall.

How do I claim a service credit from DataDack Cloud?

Report the downtime within 24 hours of noticing it, then email support@datadack.com within 30 days of the end of the billing month with the subject 'SLA Credit Request'. Include your account ID, the affected resource IDs, the dates and times of the outage with time zone, and any supporting logs or monitoring evidence. We respond within 10 business days and apply approved credits in the next billing cycle.

Does the SLA apply to free trial and promotional credit accounts?

This SLA governs every DataDack Cloud account, but availability commitments and service credits apply only to paid Eligible Resources. Free-tier, trial, promotional-credit, beta and preview resources are provided without an availability commitment.

How fast does DataDack Cloud respond to a critical support ticket?

Critical (P1) tickets — where production resources are unreachable with no workaround — receive a human first response within 1 hour, 24×7×365, with progress updates every 2 hours until the incident is mitigated.

Does scheduled maintenance count against the SLA?

No. Scheduled maintenance announced at least 48 hours in advance is excluded from the uptime calculation, as is emergency maintenance performed to address a security vulnerability or an imminent hardware failure. We schedule planned work between 00:00 and 06:00 IST and use live migration wherever the workload allows it.

Is DataDack responsible for backing up my data?

No. We provide snapshot and scheduled-backup tooling, but selecting, running and testing a backup and recovery strategy is your responsibility. Resource deletion is permanent, and this SLA does not cover the integrity or security of data held inside your own instances.

Service Level Agreement

Guaranteed performance, defined standards

We own the metal in our Noida region, so our availability commitments are ours to keep — not a reseller's promise passed along to you. This agreement sets out what we commit to, how we measure it, and exactly what you get if we fall short.

Effective July 10, 2026 Continuously monitored Credits up to 100% of monthly charges

Single-instance availability

99.9%

Monthly uptime commitment for every running virtual machine in a single availability zone, measured from independent external vantage points.

Multi-AZ availability

99.9%

Where your workload runs across two or more availability zones, the commitment is assessed at the region level — losing one zone is not downtime while another can still serve the workload.

API response time

< 200 ms

Median control-plane API response for provisioning, describe and metadata calls originating within the Noida region.

Support first response

1–4 hrs

Time to a human first response, set by the priority of the ticket. P1 incidents are handled 24×7×365.

1. Applicability

Who and what this covers

This Service Level Agreement (“SLA”) sets out the availability commitments, support standards and compensation structure that DataDack provides to holders of a DataDack Cloud account. It applies to every account — paid, free-trial or promotional-credit — whether or not a separate contract has been signed, and is incorporated into the Terms of Service. Availability commitments and service credits, however, apply only to paid Eligible Resources. It is an agreement between DataDack and the account holder and creates no rights for any third party.

The following DataDack Cloud services are within scope:

Virtual machines and dedicated cloud servers
Virtual Private Cloud (VPC), subnets, routing and security groups
Public IPv4/IPv6 addresses, static IPs and load balancers
Block storage volumes, images and snapshots
Backup and snapshot scheduling
The DataDack Cloud console, public API and cloud shell

2. Uptime commitment

What we commit to, per service

Availability is measured per resource, per billing month, in whole minutes. We probe from at least two independent external vantage points so a fault in a single probe path is never counted against you — and never hides a real outage.

Service	Monthly uptime commitment	How availability is measured
Single virtual machine (one availability zone)	99.9%	External reachability of the instance's attached network interface
Multi-AZ deployment (two or more AZs in a region)	99.9%	Region-level availability — the region is down only if no AZ can serve the workload
Block storage volumes	99.95%	Volume attachment and read/write availability to the attached instance
VPC networking, static IPs & load balancers	99.95%	Packet delivery between the instance and our network edge
Control plane (console & public API)	99.5%	Share of well-formed API requests not returning a 5xx error
Images, snapshots & scheduled backups	99.9%	Availability of create, list and restore operations

Live incident status is published at datadack.cloud/status, with a post-incident note after every event that affects a commitment.

3. Reference

What each percentage actually allows

Uptime percentages are easy to quote and hard to picture. This is the same table in minutes, based on a 30-day month.

Availability	Maximum downtime per month	Per year
99.99%	4 min 19 sec	52 min 36 sec
99.95%	21 min 36 sec	4 hr 23 min
99.9%	43 min 12 sec	8 hr 46 min
99.5%	3 hr 36 min	1 day 19 hr
99.0%	7 hr 12 min	3 days 15 hr

4. Service credits

What you get if we miss

If a resource misses the monthly commitment that applies to it, you are entitled to a service credit calculated as a percentage of that resource's charges for the affected month. Each resource is assessed against its own commitment from the table above, so the same bands apply whether the shortfall is against 99.9%, 99.95% or 99.5%.

Monthly uptime percentage	Equivalent downtime	Service credit
Below the applicable commitment, but at or above 99.0%	Up to 7 hr 12 min	10%
Below 99.0%, but at or above 95.0%	7 hr 12 min – 36 hr	30%
Below 95.0%	More than 36 hr	100%

How credits are calculated and applied

Credits are calculated per incident, against the monthly recurring charges for the affected resource in the billing month in which the downtime occurred.
Where a resource ran for part of a month only, the credit is calculated pro rata on that resource's charges for the days it was running.
You may elect to take an approved credit either as prepaid balance or as an equivalent extension of service time on the affected resource.
Credits are applied to your DataDack Cloud balance or future invoices. They have no cash value, are not transferable, and are never disbursed as a refund or other payment.
Credits are not available on an account with overdue invoices or an unpaid balance for the current or a subsequent billing cycle. Settle the account first, then claim.
Total credits for any single resource in any single month are capped at 100% of that resource's charges for the month.
Any dispute over a credit determination is resolved by both parties in good faith, and either party may escalate it under the Terms of Service.

5. Reporting & claiming

Report the downtime, then claim the credit

Two separate clocks run here, and missing either one forfeits the credit — so they are worth reading closely.

1
Tell us within 24 hours of noticing it
Report downtime from a registered contact on the account — through the console or by emailing support@datadack.com — within 24 hours of discovering it. Continuing to run an impaired resource without telling us makes that period ineligible for credit.
2
The clock starts at detection, not at your email
The downtime window opens at the earlier of your notification timestamp and the moment our own monitoring recorded the fault, and closes when the incident is resolved. You are not penalised for downtime we had already detected.
3
We investigate and keep you updated
We reconcile the report against our monitoring and incident timeline, and keep you updated at the cadence set by the ticket's priority until the incident is mitigated.
4
Claim the credit within 30 days
Email support@datadack.com with the subject “SLA Credit Request” within 30 days of the end of the billing month concerned, quoting your account ID, affected resource IDs, outage dates and times with time zone, and any supporting logs or third-party monitoring output. We respond within 10 business days.

6. Support

Priorities and response times

Every ticket is triaged to a priority based on its impact on your production workload. Business hours are Monday to Friday, 10:00–19:00 IST, excluding Indian public holidays.

Priority	Description	First response	Coverage	Updates
Critical (P1)	Production resources are unreachable or unusable with major business impact, and no workaround exists.	1 hour	24×7×365	Every 2 hours until mitigated
High (P2)	A service is partially impaired or significantly degraded, with significant impact but a workaround available.	2 hours	24×7	Every 8 hours
Medium (P3)	A non-critical issue affecting a single resource, with limited impact on your operations.	4 hours	Business hours (IST)	Daily
Low (P4)	General enquiries, quota increases, billing questions and feature requests.	1 business day	Business hours (IST)	As needed

Response targets describe the time to a substantive first response from an engineer, not the time to resolution — a resolution time cannot be honestly guaranteed for faults whose cause is not yet known. Raise tickets from the console or by emailing support@datadack.com from a registered contact on the account.

7. Maintenance

Planned and emergency work

Scheduled maintenance

Announced at least 48 hours in advance by email and on the status page. Planned in low-traffic windows between 00:00 and 06:00 IST, and performed with live migration wherever the workload allows it, so most maintenance is invisible to running instances.

Emergency maintenance

Occasionally a critical security vulnerability or an imminent hardware failure has to be addressed immediately. We give as much notice as the situation permits and publish a post-incident note on the status page afterwards.

8. Exclusions

What is not counted as downtime

These events are excluded from the uptime calculation. We list them in full rather than behind a general disclaimer, so you can architect around them.

Scheduled maintenance announced at least 48 hours in advance, and emergency maintenance carried out to address a security vulnerability or imminent failure.
Force majeure events outside our reasonable control, including natural disasters, fibre cuts outside our facility, grid failure beyond our redundancy window, civil unrest and government action.
Changes to law or regulation, or a direction from a regulator or law-enforcement agency, that requires us to interrupt a service.
Faults originating in your own operating system, applications, container runtime, kernel, or in software from a marketplace or third-party image.
Misconfiguration by you or anyone acting under your account — including security-group and firewall rules, routing, IAM policies that lock out access, exhausted disk space, or resources sized below what the workload requires.
Modifications or alterations to a service that we make at your request, and downtime caused by an action you initiated such as a reboot, resize, snapshot restore, volume detach or instance stop.
Incomplete or inaccurate information supplied by you during account or service setup, including an unreachable technical contact.
Suspension or termination carried out under the Terms of Service, the Acceptable Use Policy, or for an insufficient prepaid credit balance.
Suspension arising from an incomplete or failed identity verification (KYC) check where a public IP address has been allocated to your account.
Conditions beyond our network demarcation point — the public internet, internet exchange or transit peering points, your access ISP, DNS you operate, or your own on-premises equipment and connectivity.
Volumetric denial-of-service attacks that exceed the scrubbing capacity published for your plan.
Scheduled or customer-requested offline backups, restores and migrations, during which a resource is intentionally quiesced.
Hardware damage caused by negligence, misuse, or use of the service for a purpose other than the one it was provisioned for.
Periods during which you continued to use an impaired resource without reporting it, and support requests where investigation finds no fault.
Free-tier, trial, promotional-credit, beta and preview resources, which are provided without any availability commitment.

9. Your responsibilities

Where this SLA stops

An availability commitment on the infrastructure is not a commitment on everything running above it. These three points are the ones customers most often assume are covered.

Backups are yours to hold

We provide snapshot and scheduled-backup tooling, but you are responsible for choosing an appropriate backup and recovery strategy, running it, and periodically testing that a restore actually works. Deletion of a resource is permanent; a snapshot you never took cannot be recovered by us.

Security inside the instance is yours

Under the shared responsibility model we secure the infrastructure, hypervisor and network isolation. Passwords, SSH keys, API credentials, cryptographic material, OS patching and application security sit with you — and this SLA does not extend to the integrity of data you store on your own resources.

Architect for the commitment you want

A single instance in a single availability zone carries the 99.9% commitment, and so does a multi-AZ deployment — but a multi-AZ deployment is assessed at the region level, meaning the loss of one zone does not count as downtime if another zone can still serve the workload. Spreading a workload across zones is what turns a host failure into a non-event rather than a credit claim.

10. Definitions

How we define the terms

Downtime: A period of one or more consecutive whole minutes during which an Eligible Resource is unavailable, as confirmed by our monitoring from at least two independent external vantage points. Isolated packet loss and single failed requests that do not span a full minute are not counted.
Monthly Uptime Percentage: Calculated per resource as ((total minutes in the billing month − Downtime minutes) ÷ total minutes in the billing month) × 100, excluding every minute attributable to an event listed under Exclusions.
Eligible Resource: A paid, running resource in a region we operate, under an account in good standing with no overdue balance and with identity verification completed where it is required.
Multi-AZ deployment: A workload with running, independently schedulable instances in at least two availability zones of the same region, arranged so that the loss of one zone does not take the workload offline.
Service Credit: A credit applied to your DataDack Cloud prepaid balance or future invoice — or, at your election, an equivalent extension of service time — calculated as a percentage of the charges billed for the affected Eligible Resource in the month in which the Downtime occurred.

11. Exclusive remedy

The limit of this agreement

Except as expressly set out in a signed master services agreement, the service credits described here are your sole and exclusive remedy, and DataDack's sole and exclusive liability, for any unavailability, non-performance or other failure to deliver the Services. This SLA does not extend the liability position set out in the Terms of Service. We may update this SLA from time to time; material changes are communicated through the console or by email before they take effect, and the revised version applies to billing months beginning after that date.

FAQ

The SLA, answered

What uptime does DataDack Cloud guarantee?: DataDack Cloud commits to 99.9% monthly uptime for each running virtual machine, measured per instance and, for multi-AZ deployments, at the region level. Block storage, VPC networking, static IPs and load balancers carry a 99.95% commitment, and the console and public API carry 99.5%. Missing a commitment entitles you to a service credit of 10%, 30% or 100% of that resource's monthly charges depending on the size of the shortfall.
How do I claim a service credit from DataDack Cloud?: Report the downtime within 24 hours of noticing it, then email support@datadack.com within 30 days of the end of the billing month with the subject 'SLA Credit Request'. Include your account ID, the affected resource IDs, the dates and times of the outage with time zone, and any supporting logs or monitoring evidence. We respond within 10 business days and apply approved credits in the next billing cycle.
Does the SLA apply to free trial and promotional credit accounts?: This SLA governs every DataDack Cloud account, but availability commitments and service credits apply only to paid Eligible Resources. Free-tier, trial, promotional-credit, beta and preview resources are provided without an availability commitment.
How fast does DataDack Cloud respond to a critical support ticket?: Critical (P1) tickets — where production resources are unreachable with no workaround — receive a human first response within 1 hour, 24×7×365, with progress updates every 2 hours until the incident is mitigated.
Does scheduled maintenance count against the SLA?: No. Scheduled maintenance announced at least 48 hours in advance is excluded from the uptime calculation, as is emergency maintenance performed to address a security vulnerability or an imminent hardware failure. We schedule planned work between 00:00 and 06:00 IST and use live migration wherever the workload allows it.
Is DataDack responsible for backing up my data?: No. We provide snapshot and scheduled-backup tooling, but selecting, running and testing a backup and recovery strategy is your responsibility. Resource deletion is permanent, and this SLA does not cover the integrity or security of data held inside your own instances.