SLA 99.9% for Hosting: How Much Downtime Does That Percentage Hide?
Converting 99.9%, 99.95%, and 99.99% into minutes, we examine service coverage, exclusions, and service credits to compare hosting plans by their terms rather than by the number of nines.
In this article
99,9% доступности в месячном SLA допускают около 43 минут 12 секунд простоя в 30-дневном месяце — если договор действительно считает каждую такую минуту и применяет показатель к вашей конфигурации. Для 31 дня это уже 44 минуты 38 секунд. Поэтому до выбора хостинга проверьте не только процент, но и охват услуги, определение недоступности, исключения, способ измерения и порядок получения сервисного кредита. Сам по себе красивый процент не обещает, что интернет-магазин никогда не остановится.
Переведите процент в минуты
Для месячного показателя используется простой расчёт: допустимый простой = число минут в расчётном месяце × (1 − SLA / 100). Месяцы разной длины дают разный результат, поэтому значение «за месяц» нельзя автоматически превращать в один постоянный годовой лимит.
Заявленная доступность | 30 дней, 43 200 минут | 31 день, 44 640 минут |
|---|---|---|
99,5% | 3 ч 36 мин | 3 ч 43 мин 12 с |
99,9% | 43 мин 12 с | 44 мин 38 с |
99,95% | 21 мин 36 с | 22 мин 19 с |
99,99% | 4 мин 19 с | 4 мин 28 с |
Учебный расчёт: в 30-дневном месяце 43 200 минут. Если подтверждённый простой составил 62 минуты, наблюдаемая доступность по простой формуле равна (43 200 − 62) / 43 200 × 100% ≈ 99,856%. Это ниже 99,9%. Но договорный вывод делать рано: сначала нужно применить именно определение простоя и исключения провайдера. Это расчёт, а не измерение конкретного сервиса.
Проверьте, к какой архитектуре относится процент
Вот тут интересно: у одного провайдера разные конфигурации могут иметь разные цели доступности. В действующем соглашении AWS для Amazon EC2 региональный показатель 99,99% действует, когда все работающие экземпляры одновременно распределены по двум или более зонам доступности одного региона; если в регионе только одна зона — как минимум по двум регионам. Для отдельного экземпляра указан показатель 99,5%. В текущем SLA Google Compute Engine для Premium Tier в регионах, кроме Стокгольма, несколько зон получают 99,99%, один экземпляр большинства семейств — 99,9%, а один экземпляр оптимизированного по памяти семейства — 99,95%. Для Стокгольма показатель нескольких зон составляет 99,95%, а одного экземпляра остальных семейств — 99,9%. Эти примеры не сравнивают качество облаков: они показывают, почему число без схемы размещения и региона мало что объясняет.
точное название услуги, тарифа, региона и сетевого уровня;
один сервер или несколько независимых экземпляров;
требуется ли распределение по зонам, балансировщик или другая отказоустойчивая схема;
рассчитывается показатель на экземпляр, проект, регион или весь аккаунт.
У Yandex Compute Cloud на странице сервиса указан SLA 99,95% для доступности виртуальных машин, а документация ведёт к отдельным общим условиям и уровням обслуживания. Это хороший повод открыть не только карточку продукта, но и связанный договорный документ: короткая цифра на витрине не раскрывает метод расчёта.
Уточните, что считается простоем
Пользователь может видеть неработающую корзину, пока виртуальная машина отвечает на сеть. И наоборот, внешний мониторинг способен зафиксировать сетевую ошибку из одной точки, хотя сервис доступен по другому маршруту. SLA обычно описывает конкретное техническое событие: например, потерю внешней связности, недоступность диска или одновременную недоступность всех предусмотренных экземпляров.
какой пользовательский или инфраструктурный признак запускает отсчёт;
какая минимальная длительность события учитывается;
чьи журналы и часы считаются источником времени;
входят ли плановые работы, ошибки клиента, сторонние сервисы и превышение квот;
как объединяются несколько коротких событий в один период простоя.
Публичная страница статуса полезна как наблюдение, но не заменяет договор. На странице статуса General iT прямо указано, что проценты основаны на выполненных проверках из определённой точки и не являются заявленным SLA. В публичной оферте показатель доступности или компенсация действуют только при конкретном согласовании. Для вашей услуги приоритет имеет заказ и применимые условия, а не число на общей странице.
Сервисный кредит не равен возмещению потерь бизнеса
В облачных SLA типичный результат нарушения — кредит на будущие платежи за затронутую услугу, а не автоматическая выплата стоимости потерянных заказов. AWS требует подать обращение с указанными данными до конца второго расчётного периода после инцидента. Google требует обратиться в поддержку в течение 60 дней с момента возникновения права на сервисный кредит и приложить журналы с датами и временем периодов недоступности. У другого провайдера сроки, доказательства и размер кредита могут отличаться.
Если месячная услуга в учебном примере стоит 12 000 ₽, а условия дают кредит 10%, результатом будут 1 200 ₽ на будущие платежи — только при выполнении правил заявки. Это не оценка ущерба магазина и не обещание конкретного провайдера.
Шесть вопросов до оплаты
Где закреплён SLA: в тарифе, заказе, договоре или отдельном приложении?
Какой именно сервис и какая конфигурация покрыты показателем?
Как определяется начало и конец недоступности и какие события исключены?
За какой период считают процент: календарный месяц, расчётный месяц или другой интервал?
Какой кредит предусмотрен, к какой сумме он применяется и нужно ли подавать заявку?
Какие сроки, журналы, номера обращений и иные доказательства потребуются?
Если ответы остаются только в рекламном описании, попросите у поставщика точную редакцию условий до заказа. При сравнении обычного виртуального хостинга отдельно сопоставьте ресурсы, ограничения, поддержку, резервные копии, цену первого срока и продления; SLA отвечает лишь на одну часть выбора.
Что сохранить после инцидента
время начала и окончания с часовым поясом;
затронутый домен, сервер, регион и пользовательский сценарий;
HTTP-коды, сетевые ошибки и журналы без секретов и персональных данных;
результаты независимого мониторинга и сообщения провайдера за тот же интервал;
номер обращения и ответ поддержки;
расчёт процента по формуле и определениям именно вашего SLA.
Достаточный результат выбора — не максимальное число девяток, а понятная связка: покрытая конфигурация, измеримый признак недоступности, известные исключения, рабочий способ фиксации и реальный порядок получения кредита. Источники и условия проверены 3 ноября 2026 года. Перед покупкой или заявкой на компенсацию сверяйте актуальную редакцию договора: SLA меняются, а наблюдаемая доступность конкретного сайта зависит ещё и от приложения, DNS, базы, интеграций и вашей архитектуры.
A 99.9% availability SLA for a month allows for approximately 43 minutes and 12 seconds of downtime in a 30-day period, provided the contract actually counts every such minute and applies the metric to your configuration. For a 31-day month, this allowance rises to 44 minutes and 38 seconds. Therefore, before choosing a hosting provider, verify not only the percentage but also the service coverage, the definition of unavailability, exclusions, the measurement method, and the procedure for obtaining a service credit. A high percentage alone does not guarantee that your online store will never go offline.
Convert the percentage to minutes
The monthly figure is calculated using a simple formula: allowable downtime = number of minutes in the billing month × (1 − SLA / 100). Since months vary in length, a 'per month' value cannot be automatically converted into a single fixed annual limit.
Advertised availability | 30 days, 43,200 minutes | 31 days, 44,640 minutes |
|---|---|---|
99.5% | 3 h 36 min | 3 h 43 min 12 s |
99.9% | 43 min 12 s | 44 min 38 s |
99.95% | 21 min 36 s | 22 min 19 s |
99.99% | 4 min 19 s | 4 min 28 s |
Calculation example: a 30-day month contains 43,200 minutes. If confirmed downtime totals 62 minutes, the observed availability using the simple formula is (43,200 − 62) / 43,200 × 100% ≈ 99.856%. This is below 99.9%. However, drawing a contractual conclusion is premature: first, you must apply the specific definition of downtime and the provider's exclusions. This is a calculation, not a measurement of a specific service.
Check which architecture the percentage refers to
Here is the interesting part: different configurations from the same provider can have different availability targets. In the current AWS agreement for Amazon EC2, the regional 99.99% figure applies when all running instances are simultaneously distributed across two or more availability zones within a single region; if a region has only one zone, the requirement is at least two regions. For a single instance, the specified figure is 99.5%. In the current SLA for Google Compute Engine for the Premium Tier, regions other than Stockholm receive 99.99% for multiple zones, 99.9% for a single instance of most families, and 99.95% for a single instance of the memory-optimized family. For Stockholm, the multiple-zone figure is 99.95%, and the single-instance figure for other families is 99.9%. These examples do not compare cloud quality; they illustrate why a number without context regarding placement scheme and region explains very little.
the exact name of the service, tariff, region, and network level;
one server or several independent instances;
whether distribution across zones, a load balancer, or another fault-tolerance scheme is required;
whether the figure is calculated per instance, project, region, or the entire account.
On the Yandex Compute Cloud service page, the SLA for virtual machine availability is listed as 99.95%, while the documentation links to separate general terms and service levels. This is a good reason to open not only the product card but also the related contract document: the short figure on the display does not reveal the calculation method.
Clarify what counts as downtime
A user may see a non-functional shopping cart while the virtual machine responds to network requests. Conversely, external monitoring may record a network error from a single point even though the service is accessible via another route. SLAs typically describe a specific technical event: for example, loss of external connectivity, disk unavailability, or simultaneous unavailability of all provisioned instances.
which user or infrastructure trigger starts the countdown;
what minimum event duration is taken into account;
whose logs and timestamps are considered the time source;
whether scheduled maintenance, customer errors, third-party services, and quota overruns are included;
how multiple short events are combined into a single downtime period.
The public status page is useful for observation but does not replace a contract. The General iT status page explicitly states that percentages are based on completed checks from a specific point and do not constitute a claimed SLA. In the public offer, availability metrics or compensation apply only under specific agreement. For your service, the order and applicable terms take precedence over the number shown on the general page.
Service credits do not equal compensation for business losses
In cloud SLAs, the typical result of a breach is a credit toward future payments for the affected service, not an automatic payout for lost order value. AWS requires submitting a claim with specified data by the end of the second billing period following the incident. Google requires contacting support within 60 days of the right to a service credit arising, along with logs containing dates and times of unavailability periods. For another provider, deadlines, evidence requirements, and credit amounts may differ.
If a monthly service in the example costs 12,000 ₽ and the terms offer a 10% credit, the result is 1,200 ₽ for future payments—only if the application rules are met. This is not an assessment of store damage nor a promise from a specific provider.
Six questions before payment
Where is the SLA defined: in the tariff, order, contract, or a separate appendix?
Which specific service and configuration are covered by the metric?
How are the start and end of downtime defined, and what events are excluded?
Over what period is the percentage calculated: calendar month, billing month, or another interval?
What service credit is provided, to which amount does it apply, and is an application required?
What timelines, logs, ticket numbers, and other evidence will be required?
If answers remain only in promotional descriptions, request the supplier's exact terms before placing an order. When comparing standard virtual hosting, separately evaluate resources, limits, support, backups, initial and renewal pricing; an SLA addresses only one part of the decision.
What to preserve after an incident
start and end times with time zone;
affected domain, server, region, and user scenario;
HTTP codes, network errors, and logs without secrets or personal data;
results from independent monitoring and provider reports for the same interval;
ticket number and support response;
percentage calculation using the formula and definitions specific to your SLA.
A sufficient selection result is not the maximum number of nines, but a clear combination: a covered configuration, a measurable unavailability indicator, known exceptions, a working method for recording, and a real process for obtaining a credit. Sources and terms were verified on November 3, 2026. Before purchasing or applying for compensation, check the current version of the contract: SLAs change, and the observed availability of a specific site also depends on the application, DNS, database, integrations, and your architecture.
Discussion 0
Share your experience and ask questions. Comments without links appear after editorial review.
No comments yet. Start the discussion.