Service Level Agreement (SLA)

Service Level Agreement
What we commit to, how it is measured, and how credits work

This Service Level Agreement sets out the framework we operate under: which services are covered, how availability is measured, what happens when we fall short, and what is excluded. It forms part of our Terms of Service.

The specific availability commitment that applies to your services is stated in your order or agreement with us. We size commitments to the architecture you actually buy rather than publishing one number for every workload, because a single virtual machine and a triple-replicated storage cluster do not carry the same risk. If you are evaluating us and need the figures before you sign, ask an engineer — we will put them in writing.

Covered services

Availability commitments are made per service, not as a single blended figure across your account:

Compute. Availability of the hypervisor and host layer for your instances — see compute platform. A single instance on a single host is inherently a single point of failure; workloads that need a higher commitment are architected across hosts, and we will tell you plainly which category yours falls into.

Block storage. Availability and durability of your volumes. Every volume is replicated three times across separate nodes, which is what allows a materially stronger commitment here than for a single instance — see storage architecture.

Network and connectivity. Availability of the switching fabric and upstream transit. Hosts have multiple NIC paths into redundant switching with tier-1 upstream — see network fabric. Dedicated circuits and BGP peering are covered under the terms of the specific circuit: see private circuits and peering.

VPN and load balancing. Availability of the private access and traffic distribution tier included with every plan — see networking and VPN.

Colocation power and cooling. For customers with equipment racked with us, power and environmental commitments for the facility rather than for the hardware itself, which remains yours — see colocation and BYO hardware.

How availability is measured

Unavailability means a total loss of access to a covered service that is attributable to MarQi Cloud infrastructure. Degraded performance that still permits the service to function is handled as a support incident rather than as unavailability, unless your agreement defines a specific performance threshold.

Measurement window. Availability is calculated per calendar month, per affected service, as the percentage of minutes in the month during which the service was available.

How the clock runs. An unavailability period begins at the earlier of the moment our monitoring detects it or the moment you open a ticket, and ends when service is restored. Our NOC monitors the platform continuously at fixed intervals — see status and monitoring for what is watched. We use our own monitoring records as the measurement of record, and we will share the relevant data with you when a claim is made.

Scope of an incident. Only the affected service is counted. If storage is unavailable but your instances and network are not, the shortfall applies to storage.

Service credits

When we miss a commitment, the remedy is a service credit against the affected service. The mechanism works as follows:

Credits are tiered. The larger the shortfall against the commitment, the larger the credit — a marginal miss and a severe outage are not treated the same. The credit schedule that applies to you is set out in your order or agreement.

Credits apply to the affected service. They are calculated against the monthly fee for the service that fell short, not against your total invoice.

Credits are capped. The total credit for any single month cannot exceed the monthly fee for the affected service.

Credits are credits. They are applied against a future invoice. They are not cash refunds, and they are the exclusive remedy for a missed availability commitment.

Credits are claimed, not automatic. We do not apply them silently — see the claim process below.

Exclusions

The following do not count as unavailability:

Scheduled maintenance carried out with advance notice, as described in the next section.

Emergency maintenance genuinely necessary to protect the platform, your data, or other customers — for example patching an actively exploited vulnerability. We will notify you as soon as practicable.

Anything within your control: your operating system, application, configuration or capacity choices; credentials and access management; workloads that exhaust the resources you provisioned; and changes you or your agents make.

Anything beyond our demarcation point: your premises, your own hardware, your carrier or last-mile connectivity, your DNS if hosted elsewhere, and the public internet between our edge and your users.

Suspension under the Acceptable Use Policy or for non-payment, in accordance with our Terms of Service.

Force majeure and events genuinely outside our reasonable control.

Features identified as beta, preview or trial, which carry no availability commitment.

Scheduled maintenance

Infrastructure that is never maintained is infrastructure that fails unpredictably, so some maintenance is unavoidable. Our practice is to give advance notice, to schedule disruptive work outside normal business hours where the work permits it, and to publish both planned windows and live state on our status page, where you can subscribe to notifications. Where maintenance can be performed without interrupting your workload — live migration, rolling updates across redundant paths — we do that instead of taking a window.

How to claim a credit

Open a ticket through the support portal and include the affected service and resources, the date and time range with time zone, and any evidence you have such as monitoring output or log excerpts. Claims must be submitted within the window stated in your agreement. We will compare your report against our monitoring records, tell you what we find, and apply any credit due to your next invoice. If we disagree with a claim we will show you the data behind that conclusion rather than simply declining it.

Data protection is a shared responsibility

An availability commitment is not a backup commitment. We replicate volumes across separate nodes and include snapshots and backups in every plan, but replication protects against hardware failure — not against deletion, corruption, or a fault in your own application. Configuring a protection schedule that matches your recovery requirements, and verifying that restores work, remains yours.

Changes to this SLA

If we change this SLA in a way that materially reduces your rights, we will give you notice before it takes effect. Commitment levels recorded in a signed order or agreement are not changed by an update to this page.

Questions

If you need the specific figures for a workload you are planning, or a signed SLA for a procurement process, talk to an engineer. Live platform state is always on the status page.

MarQi Cloud
190 Bluegrass Valley Pkwy, Alpharetta, GA 30005, United States
Email: support@marqi.cloud · Phone: +1-770-369-9321

Related: Terms of Service · Acceptable Use Policy · Status Page · All legal documents