Service level agreement
0. This document confers no rights on anyone today
Say it once more, on the document most likely to be read as a promise: this service level agreement is a draft, it applies to no service, and it gives nobody a right to anything. Andrii Co., a Washington for-profit corporation (UBI 604505773), doing business as Andrii Cloud sells no colocation, transit or managed service as of the date above.
It is published because a buyer evaluating a small provider should be able to read the remedy before spending time on an enquiry, and because an SLA that appears only after a contract is signed tells you something about the provider. When there is a service, the SLA that applies will be the one attached to your signed service order — and if it differs from this draft, that one governs and this page has no effect.
Nothing here is a warranty, and nothing here creates an obligation to launch a service, to launch it on any date, or to launch it in this shape.
1. Scope
This SLA would apply to colocation and network services identified in a customer's service order, for the affected service only, and would be the customer's sole and exclusive remedy for a failure to meet a service level described here.
It would not apply to: this website; customer equipment, software or configuration; managed services, which would carry their own targets in the managed-services schedule of the service order; a service in a suspension or termination period under the agreement or the acceptable use policy; or anything provided at no charge or on a trial basis.
Capitalised terms not defined here would take their meaning from the master services agreement, published in draft at colocation terms.
2. What would be measured, and where
The demarcation is our edge. Availability would be measured to the customer-facing port we hand off on, and to the delivery of power at the customer's cabinet position — not to the customer's equipment, an application on it, or a destination on the wider internet, none of which we control.
Availability would be measured from monitoring points we operate outside our own network, so that the measurement does not depend on the network being measured. A measurement taken from inside the thing you are measuring is not a measurement, and every provider that only checks from within its own network discovers this the same way.
We do not operate a public status page, and this document does not promise one. If we publish one, it will get its own URL and a sentence here in the same edit. During an incident affecting your service we would notify you directly.
A service would be treated as unavailable when it is completely unusable — no power at the cabinet position, or total loss of packet delivery on the handoff port — for a continuous period of at least five minutes, as measured above and confirmed in our own records. Degradation short of that, including packet loss, latency and jitter, would not count as unavailability, and no target for those is offered here.
3. Power
We would target continuous delivery of the committed power at the customer's cabinet position, within the tolerances of the facility's electrical distribution.
The customer's equipment must remain within its committed continuous draw, calculated on the derated capacity of the circuit rather than its nameplate rating. A loss of power caused by the customer exceeding that commitment, or by a fault in the customer's own equipment or cabling, is not unavailability and earns no credit — including where it trips a breaker shared with nothing else.
4. Network
We would target continuous delivery of packets on the customer handoff port, from the port to our network edge.
Two exclusions are stated up front rather than buried in the list below, because they are the ones most likely to be argued about:
- Denial-of-service mitigation is not unavailability. Filtering, rate-limiting or announcing an address to a remotely-triggered blackhole to protect the network is a mitigation. It will make that address unreachable, which is the purpose, and it earns no credit.
- A failure upstream of us, or inside an internet exchange, is not our unavailability where our own network and handoff are delivering normally. We would tell the customer what we know, and we would pursue it with the party responsible; we would not credit for it.
5. Remote hands
Remote hands targets would be response targets — the time in which we begin work — and never resolution targets. What a pair of hands finds in a rack is not something a contract can schedule.
- Severity 1 — service down. The customer's service is completely unavailable. Target response: within 1 hour, at any hour of any day.
- Severity 2 — service degraded. The service is impaired but usable. Target response: within 4 hours during business hours, and within 8 hours otherwise.
- Severity 3 — scheduled work. Anything requested rather than broken: a reboot, a cable move, a media swap, an eyes-on check. Target response: within 1 business day, or at the scheduled time if one was agreed.
Severity would be set by us on the facts, not by the wording of the request. A missed remote-hands response target would not earn an availability credit; it would be handled under the chronic-failure clause below if it kept happening.
Access to the facility would be escorted in all cases, so a remote-hands response also depends on the facility operator's own access process, which we do not control.
6. Credits
Credits would be calculated per affected service, per calendar month, on cumulative unavailability as measured in clause 2:
- more than 1 hour and up to 4 hours — a credit of 5% of that month's recurring charge for the affected service;
- more than 4 hours and up to 8 hours — 10%;
- more than 8 hours and up to 24 hours — 25%;
- more than 24 hours — 50%.
Credits in any calendar month are capped at one month's recurring charge for the affected service, however many incidents there were and however long they lasted. A credit is applied against a future invoice; it is not a refund, it is not payable in cash, and it does not survive termination.
No credit is payable while the account has an overdue balance, and a credit does not excuse payment of the invoice it is claimed against.
7. How a credit would be claimed
A claim would be made in writing, within 5 business days of the end of the incident, to the address we give for service notices. It should identify the service, the date, the start and end of the unavailability as the customer observed it, and any evidence the customer has.
We would respond within 10 business days, and our own measurements would determine the outcome. A claim made after the 5-day window would not be considered — not because the failure did not happen, but because neither side can reconstruct a month-old incident from memory.
Claiming a credit would be the customer's sole and exclusive remedy for a failure to meet a service level, and accepting one would not waive any right in respect of a different failure.
8. Exclusions
No credit would be payable for unavailability caused by or during:
- scheduled maintenance notified under clause 9, or emergency maintenance to prevent imminent harm to the network or to other customers;
- anything caused by the customer or by anyone using the service through the customer — equipment failure, configuration, exceeding a committed power or bandwidth level, or a breach of the acceptable use policy;
- denial-of-service traffic and its mitigation, including filtering, rate-limiting and blackholing;
- suspension under the acceptable use policy, under the agreement, or for non-payment;
- a failure of the facility in which the equipment sits — power, cooling, access or building systems — or of an upstream network, an internet exchange, or another operator, to the extent our own network and handoff continued to deliver;
- force majeure, including natural events, fire, flood, labour action, civil disturbance, government action and network-wide internet events;
- a request from the customer, or an act we take at the customer's instruction; and
- any period for which the customer cannot show, and we cannot confirm, that the service was actually unavailable.
9. Maintenance
We would notify standard maintenance at least 7 days in advance and urgent maintenance at least 24 hours in advance, by email to the technical contact on the account. Emergency maintenance — work that cannot wait without risking harm to the network, to the facility or to other customers — would be notified as soon as we reasonably can, which may be after it has begun.
We would prefer maintenance windows outside North American business hours, and we would not promise a fixed window: a window fixed in a contract becomes the one hour when the thing you need to fix cannot be fixed.
10. Chronic failure, and the right to leave
This clause is the part of the document that costs us something, and it is here on purpose. A remedy that only ever produces small credits gives a provider no reason to fix the underlying problem, and gives a customer no way out.
If credits become payable in three or more calendar months within any rolling six-month period for the same service, the customer would be entitled to terminate that service on 30 days' written notice, without termination charge, with a pro-rated refund of any prepaid charges for the terminated period. The right would have to be exercised within 30 days of the third qualifying month, and it would be in addition to the credits, not instead of them.
The same right would apply to a single unavailability lasting more than 72 continuous hours.
11. Definitions and interpretation
"Recurring charge" would mean the monthly charge for the affected service under the service order, excluding one-time charges, usage charges, remote-hands charges and taxes.
"Business hours" and "business day" would mean 09:00 to 17:00 Pacific Time on a day that is not a Saturday, a Sunday or a United States federal holiday.
"Unavailability" would have the meaning in clause 2, and only that meaning. Degradation, latency, loss and jitter would not be unavailability, and this document offers no target for them. That is a limitation stated plainly rather than a gap: we would rather commit to less and mean it.
Questions about this draft: legal@andrii.cloud.
Andrii Co., a Washington for-profit corporation (UBI 604505773), doing business as Andrii Cloud
11826 NE 167th St, Bothell WA 98011-5456
United States