BitVPS
Запустить сервер

Сервис статус

Актуальное состояние инфраструктуры для 16 компонентов в четырёх дата-центрах. Опрашивается каждые 20 секунд внешними зондами за пределами нашей ASN; измерения публикуются как есть, включая негативные.

Обновлено 00:10 UTC Период доступности 90 дней Внешние зонды · Каждые 20 сек
BitVPS network status

Плановые работы Предстоящие

Web control panel · Rolling kernel upgrade with cgroup-v2 schedule tuning; brief p99 latency bump possible.

2026-10-17 00:00 UTC через 4 d 23 h · ~75 мин

Компоненты и история за 90 дней

Каждый столбец — один день, цвет соответствует наихудшему зафиксированному состоянию. Наведите курсор на столбец для просмотра даты и сводки за день.

Compute · IS-RKV

Iceland
99.98 % Доступность за 90 дней
Работает

Compute · NL-AMS

Netherlands
100.00 % Доступность за 90 дней
Работает

Compute · RO-BUH

Romania
100.00 % Доступность за 90 дней
Работает

Compute · CH-ZRH

Switzerland
100.00 % Доступность за 90 дней
Работает

Network · IS-RKV

Iceland
100.00 % Доступность за 90 дней
Работает

Network · NL-AMS

Netherlands
100.00 % Доступность за 90 дней
Работает

Network · RO-BUH

Romania
100.00 % Доступность за 90 дней
Работает

Network · CH-ZRH

Switzerland
100.00 % Доступность за 90 дней
Работает

Block storage · IS-RKV

Iceland
99.99 % Доступность за 90 дней
Работает

Block storage · NL-AMS

Netherlands
99.97 % Доступность за 90 дней
Работает

Block storage · RO-BUH

Romania
100.00 % Доступность за 90 дней
Работает

Block storage · CH-ZRH

Switzerland
99.96 % Доступность за 90 дней
Работает

Web control panel

100.00 % Доступность за 90 дней
Работает

Billing & payments

100.00 % Доступность за 90 дней
Работает

Anycast DDoS shield

100.00 % Доступность за 90 дней
Работает

Docs & marketing site

100.00 % Доступность за 90 дней
Работает
2026-07-15 — 2026-10-12
Работает Снижение Частичный Серьёзный

Последние инциденты

Последние 14 решённых событий по всем компонентам — автоматически обновляется при каждой загрузке страницы из наших зондов.

Oct 9, 2026 10:39–10:49 UTC

Снижение производительности Block storage · IS-RKV

NVMe device failure, RAID rebuild in progress. Полностью устранено; последующие действия отслеживаются внутри компании.

10 мин простой
Oct 7, 2026 09:48–10:35 UTC

Частичный сбой Block storage · CH-ZRH

Slow-query regression on the metadata service. Полностью устранено; последующие действия отслеживаются внутри компании.

47 мин простой
Sep 16, 2026 11:12–11:47 UTC

Частичный сбой Compute · IS-RKV

NUMA imbalance briefly elevated p99 boot times on — ~6% of hosts affected. Полностью устранено; последующие действия отслеживаются внутри компании.

35 мин простой
Sep 14, 2026 10:41–11:01 UTC

Снижение производительности Block storage · RO-BUH

Garbage-collector ran hot after a large client delete burst. Полностью устранено; последующие действия отслеживаются внутри компании.

20 мин простой
Sep 10, 2026 15:56–16:17 UTC

Снижение производительности Block storage · IS-RKV

Snapshot scheduler back-pressure cleared after tuning. Полностью устранено; последующие действия отслеживаются внутри компании.

21 мин простой
Aug 27, 2026 17:38–17:49 UTC

Снижение производительности Web control panel

Live-update websocket reconnect loop during a backend roll. Полностью устранено; последующие действия отслеживаются внутри компании.

11 мин простой
Aug 21, 2026 08:59–09:05 UTC

Снижение производительности Network · NL-AMS

RPKI-ROA validation misconfiguration on prefix via Zayo (AS6461). Полностью устранено; последующие действия отслеживаются внутри компании.

6 мин простой
Aug 21, 2026 17:04–17:27 UTC

Частичный сбой Block storage · CH-ZRH

Garbage-collector ran hot after a large client delete burst. Полностью устранено; последующие действия отслеживаются внутри компании.

23 мин простой
Aug 12, 2026 03:29–03:49 UTC

Снижение производительности Block storage · CH-ZRH

Zoned-namespace firmware upgrade on a subset of drives. Полностью устранено; последующие действия отслеживаются внутри компании.

20 мин простой
Jul 27, 2026 11:26–12:23 UTC

Частичный сбой Block storage · NL-AMS

Slow-query regression on the metadata service. Полностью устранено; последующие действия отслеживаются внутри компании.

57 мин простой

Ежемесячная доступность сводка

Суммарная доступность сервиса по всем 17 компонентам, по месяцам. Месяцы ниже 99.99 % влекут зачёт по SLA — см. SLA.

Oct 2026
99.984 %
доступность
Sep 2026
99.995 %
доступность
Aug 2026
99.996 %
доступность
Jul 2026
99.995 %
доступность
Jun 2026
99.980 %
доступность
May 2026
99.990 %
доступность

Статус и SLA Частые вопросы

Как мы измеряем аптайм, что считается инцидентом Tier-1, где подписаться и как публикуются разборы инцидентов.

How is uptime measured?
We measure uptime per service component (compute, network, storage, control plane) at one-minute granularity from independent probes in five regions. Daily and monthly figures are weighted by incident severity: a major outage counts at 100%, a partial outage at 70%, and degraded performance at 30% of its measured duration.
What counts as a Tier-1 incident?
A Tier-1 incident is a region-wide loss of customer-facing service: control-plane unreachable, all compute in a datacenter offline, or a network partition that prevents customers from reaching healthy nodes. Tier-1 events trigger an immediate banner here, an out-of-band post-mortem within 72 hours and a credit on the next invoice if SLA thresholds are breached.
Where can I subscribe to status updates?
We do not offer email, RSS or webhook subscriptions — they require user accounts or per-subscriber state, and we run an account-free status surface deliberately. This page is the canonical source: it carries a live banner while an incident is open, the per-datacenter uptime figures, and the post-mortem for every Tier-1 and Tier-2 event. Bookmark it and reload.
Do you publish post-mortems?
Yes. Every Tier-1 and Tier-2 incident receives a written post-mortem within 72 hours: timeline, root cause, customer impact, mitigation and remediation work. Post-mortems are linked from the incident entry below and clearsigned with the same PGP key used on the warrant canary, so authenticity can be verified offline.
What's the difference between Tier-1 and Tier-2 incidents?
Tier-1 is region-wide customer impact (full outage, control-plane loss). Tier-2 is partial impact: a single rack, a single transit provider degraded, or a control-plane subsystem (billing, console) impaired while compute keeps running. Both get post-mortems; only Tier-1 is eligible for SLA credits under our published 99.95% target.