„OVH nie działa" to za mało, żeby cokolwiek naprawić. OVH to osobno panel, sieć, serwer, hosting i chmura - i każda z tych warstw psuje się inaczej. Sprawdź oficjalny status swojego produktu i regionu, porównaj dostęp z drugiej sieci i nie restartuj niczego bez diagnozy.
Ta strona nie pokazuje statusu na żywo. Prowadzi cię przez odczyty, po których wiesz, czy czekać na OVH, szukać winy na własnym serwerze, czy dzwonić do supportu z konkretem. Procedury dla innych dostawców zebraliśmy na stronie o awariach zewnętrznych usług.
Zobacz, jak wygląda ten poranek bez procedury:
Poniedziałek, godzina dziewiąta. Sklep internetowy na serwerze w OVH nie otwiera się, klienci dzwonią do biura. Właściciel loguje się do panelu, panel też ledwo działa, więc klika restart serwera - dwa razy, bo za pierwszym „nic się nie stało". Po godzinie wychodzi na jaw, że zawiodła sieć w jednym centrum danych i problem minąłby sam. Sklep wstał później niż inne, bo po podwójnym twardym restarcie system plików wymagał naprawy, a w kolejce panelu wisiały sprzeczne operacje.
Restart nie był tu diagnozą, tylko zgadywaniem. Wszystko poniżej służy temu, żebyś w takiej sytuacji wykonał odczyty zamiast ruchów, których nie da się cofnąć.
Gdzie sprawdzisz oficjalny status OVHcloud?
Incydenty i planowane prace OVH publikuje na stronie OVHcloud Status (oficjalne źródło, stan na sierpień 2026). Nie czytaj jej jak lampki „działa / nie działa". Wybierz rodzinę produktu i region, w którym stoi twoja usługa:
- sieć i centrum danych - gdy łączność tracą różne usługi w jednej lokalizacji,
- Bare Metal Cloud - gdy problem dotyczy serwera dedykowanego,
- Public Cloud - gdy zawodzi instancja, storage albo sieć projektu,
- Web Cloud - gdy pada hosting, poczta, domena albo baza,
- panel i API - gdy usługa odpowiada, ale nie masz jak nią zarządzać.
Region odczytasz z dokumentacji swojej usługi albo z nazwy zasobu w panelu. Incydent o podobnej nazwie w innym regionie nie dotyczy twojego serwera - nie buduj na nim wniosków.
Jak sprawdzić, czy problem jest tylko po twojej stronie?
Zanim cokolwiek klikniesz, zapisz: nazwę usługi, region, publiczny adres, godzinę ze strefą i dokładny komunikat błędu. To są dane, których za chwilę zażąda support - a po restarcie część z nich zniknie.
Potem wykonaj trzy porównania, każde bez zmiany stanu:
- Usługa kontra panel. Otwórz publiczny adres usługi i osobno panel klienta. Sklep działa, panel nie - to inna warstwa niż całkowity brak łączności. Panel działa, sklep nie - patrz na instancję, sieć i logi systemu.
- Druga sieć. Sprawdź usługę z telefonu na LTE albo z innego łącza. Błąd widoczny tylko z jednej trasy wskazuje na operatora, lokalny DNS albo zaporę, nie na OVH.
- DNS kontra host. Sprawdź, czy domena wskazuje oczekiwany adres i czy sam adres odpowiada. To dwa różne pytania i dwie różne naprawy.
Masz monitoring z zewnętrznej lokalizacji? Porównaj jego odczyt z tym, co widzi użytkownik. Pojedynczy monitor potwierdza jedną trasę, nie wszystkie regiony.
Która decyzja pasuje do twoich odczytów?
| Status OVHcloud | Inni klienci | Twój test | Wniosek | Następny krok |
|---|---|---|---|---|
| Incydent twojego produktu i regionu | zgłaszają to samo | usługa pada z różnych sieci | awaria po stronie OVH | śledź komunikat, uruchom przygotowany plan ciągłości |
| Brak incydentu | wiele zgodnych zgłoszeń | błąd z różnych sieci | szerszy sygnał bez potwierdzenia | zbierz identyfikator usługi i eskaluj do supportu |
| Brak incydentu | cisza | błąd jednego hosta, DNS albo sieci | problem lokalny albo konfiguracyjny | diagnozuj własny serwer i logi |
| Nie sprawdzono | nie sprawdzono | nie wykonano | brak danych do werdyktu | wykonaj odczyty, zanim czegokolwiek dotkniesz |
Co robić, gdy awaria trwa?
Gdy OVH potwierdził incydent, ogranicz zmiany na dotkniętych zasobach do zera. Zachowaj logi i listę operacji, które wisiały w kolejce. Failover uruchamiaj tylko według planu spisanego wcześniej - takiego, który mówi, kto decyduje, skąd są dane, dokąd idzie ruch i po czym poznasz, że można wracać.
Trzy ruchy, które w trakcie awarii szkodzą:
- Restart serwera „na próbę". Nie naprawi awarii sieci ani panelu, a potrafi dołożyć własną szkodę - jak naprawa systemu plików w scenie z początku tekstu.
- Doraźna zmiana rekordu DNS. Bez gotowego celu z certyfikatem, danymi i konfiguracją tworzysz ruch mieszany, który trudno potem odkręcić.
- Ponawianie operacji w panelu, gdy wynik poprzedniej jest nieznany. Kolejka wykona wszystkie - także te sprzeczne.
Panel niedostępny, usługa działa? Wstrzymaj zmiany administracyjne i przeczekaj. Usługa nie działa, a status OVH milczy? Przejdź do diagnostyki błędów własnego serwera - komunikat statusowy nie zwalnia z czytania logów aplikacji.
Co przekazać do supportu OVHcloud?
Zgłoszenie „serwer nie działa" trafi do kolejki ogólnej i wróci pytaniem o szczegóły. W pierwszej wiadomości podaj identyfikator usługi, rodzinę produktu, region, publiczny adres, godzinę ze strefą, zakres użytkowników i wyniki testów z różnych sieci. Dodaj komunikaty błędów po usunięciu danych poufnych.
Rozdziel też warstwy - napisz, czy panel jest dostępny, czy DNS zwraca oczekiwany adres, czy host odpowiada i czy aplikacja zapisuje błędy. Taki podział kieruje sprawę do właściwego zespołu za pierwszym razem. Nie wysyłaj haseł, kluczy prywatnych, tokenów API ani zrzutów z danymi klientów.
Pytania o awarię OVH
Czy awaria OVH musi dotyczyć wszystkich usług?
Nie. Incydent bywa ograniczony do produktu, komponentu, regionu albo jednego centrum danych. Na OVHcloud Status odszukaj rodzinę usługi i lokalizację swojego zasobu, a potem porównaj panel, publiczny adres i dostęp z drugiej sieci. Dopiero zgodność tych odczytów mówi coś o skali.
Jak sprawdzić region usługi?
Region znajdziesz w konfiguracji projektu, w panelu klienta, w dokumentacji wdrożenia albo w nazwie zasobu. Komunikat statusowy musi wskazywać ten sam region, w którym stoi badana usługa. Jeśli nie wiesz, gdzie stoi twój serwer, ustal to dziś - w trakcie awarii będzie na to za późno.
Czy zmieniać DNS podczas awarii?
Tylko według planu przełączenia przygotowanego przed awarią. Cel zastępczy musi mieć aktualne dane, właściwy certyfikat i konfigurację aplikacji, a plan - warunek powrotu. Doraźna edycja rekordów tworzy ruch mieszany i utrudnia powrót do stanu sprzed incydentu.
Czy restart serwera pomoże?
Pomoże wtedy, gdy diagnoza wskazuje problem systemu albo procesu na tym konkretnym serwerze. Awarii sieci, centrum danych ani panelu restart nie naprawi, a zaciera ślady i potrafi dołożyć własną szkodę. Przed restartem zapisz logi, stan usług i zakres problemu.
Co wpisać do zgłoszenia OVH?
Identyfikator usługi, produkt, region, godzinę ze strefą, objaw, publiczny adres i wyniki testów z różnych sieci. Dopisz stan panelu, DNS, hosta i aplikacji oraz numer pasującego incydentu ze strony statusowej - albo zdanie, że incydentu nie znaleziono. Usuń sekrety i dane klientów.