Umowa SLA na opiekę WordPress: czas reakcji, gwarancje i co musi być w zapisach
Umowa SLA na opiekę WordPress to konkretne liczby: czas reakcji, czas naprawy, gwarancja odtworzenia z backupu w X godzin i kary umowne za przekroczenie terminów. Bez SLA płacisz za opiekę techniczną, ale nie masz czego egzekwować - warto to sprawdzić przed podpisaniem.
Kiedy firma podpisuje umowę na opiekę WordPress, zazwyczaj dostaje do ręki kilka stron ogólników. „Zapewniamy szybką reakcję”, „dbamy o bezpieczeństwo”, „wykonamy wszelkie prace konserwacyjne”. Problem w tym, że takie sformułowania nie znaczy absolutnie nic, jeśli nie ma za nimi konkretnych liczb i konsekwencji.
SLA, czyli Service Level Agreement, to część umowy, która te liczby zawiera. Określa, ile czasu ma wykonawca na odpowiedź, ile na naprawę, jak szybko odtworzy stronę po awarii i co Ci się należy, jeśli te terminy przekroczy. Jeśli tego nie ma - masz usługę, ale nie masz żadnej gwarancji.
Czas reakcji a czas naprawy: nie myl tych dwóch pojęć
To jest najczęstsze źródło nieporozumień przy odbiorze umowy. Wykonawcy często chwalą się „czasem reakcji 2 godziny”, co brzmi solidnie - ale może oznaczać tylko tyle, że po 2 godzinach ktoś odpisze „dostaliśmy Twoje zgłoszenie”.
Czas reakcji (ang. response time) to czas od złożenia zgłoszenia do pierwszego kontaktu wykonawcy. Potwierdzenie przyjęcia, przypisanie priorytetu, pytanie o szczegóły - to wystarczy, żeby zegar się zatrzymał.
Czas naprawy (ang. resolution time lub time to fix) to czas od zgłoszenia do usunięcia problemu. To jest wskaźnik, który realnie wpływa na Twój biznes, bo strona nie sprzedaje do czasu, aż błąd zostanie naprawiony.
W dobrej umowie SLA oba wskaźniki są zapisane osobno i dla różnych kategorii pilności:
Przykładowe poziomy SLA dla WordPress
| Kategoria | Czas reakcji | Czas naprawy |
|---|---|---|
| Błąd krytyczny (strona/sklep niedostępny) | 1 godz. | 4 godz. |
| Błąd poważny (główne funkcje nie działają) | 2 godz. | 8 godz. |
| Błąd standardowy (drobna usterka) | 8 godz. | 2 dni robocze |
| Zmiana lub poprawa niebiznesowa | 24 godz. | 5 dni roboczych |
Te liczby są orientacyjne - konkretna umowa zależy od pakietu i wielkości strony. Sklep WooCommerce z Przelewy24 i InPostem będzie miał inne wymogi niż wizytówka lokalna. Ale zasada jest stała: jeżeli umowa nie dzieli błędów na kategorie, to prawdopodobnie traktuje każdą awarię tak samo, co jest niebezpieczne.
Okno serwisowe: kiedy wykonawca może dotykać strony
Aktualizacje WordPress, zmiana PHP, wdrożenie nowych funkcji - każda z tych operacji może wprowadzić chwilowe zaburzenia lub, w najgorszym przypadku, awarię. Bez okna serwisowego wykonawca może robić te prace o każdej porze.
Okno serwisowe to przedział czasowy, w którym tego rodzaju prace są dopuszczalne. Dobra praktyka to na przykład: wtorek-czwartek, godz. 22:00-06:00. Dla sklepu internetowego, który mógłby mieć ruch też nocami - rozważ okno weekendowe.
Jeśli prowadzisz kampanie w Meta Ads lub Google Ads, powiedz o tym agencji przy negocjacjach. Okno serwisowe powinno omijać dni startu i szczytu kampanii - zapis w umowie może chronić przed aktualizacją w najgorszym momencie.
Dla mojego klienta z branży baby furniture (sklep WooCommerce, rynek DE) ustaliliśmy okno serwisowe na poniedziałek i wtorek w nocy - poniedziałek, bo ruch w weekend spadał i w poniedziałek rano był czas na reakcję przed szczytem tygodnia. To jeden akapit w umowie, który zaoszczędził nam niejednej dyskusji.
Gwarancja przywrócenia z backupu
To ten fragment SLA, który firmy czytają dopiero po awarii - gdy jest za późno na negocjacje.
Dobry zapis o backupie powinien zawierać trzy składowe:
Co musi być w zapisach SLA o backupie
- Częstotliwość tworzenia kopii (minimum: raz dziennie; dla sklepów z dużą rotacją zamówień: co 6 godzin)
- Miejsce przechowywania (osobny serwer lub chmura - NIE ten sam serwer co strona)
- Gwarantowany czas odtworzenia (np. "w ciągu 4 godzin od zgłoszenia" - jako konkretna liczba)
- Okres retencji (ile dni wstecz można się cofnąć - minimum 14 dni, lepiej 30)
- Procedura testowania kopii (kto i jak często weryfikuje, że backup działa)
Hosting ma własne SLA dotyczące infrastruktury - zazwyczaj gwarantuje 99,9% dostępności serwera. To nie to samo co gwarancja działania Twojej aplikacji WordPress. Błąd wtyczki, atak, nieudana aktualizacja - to problemy aplikacyjne, które hosting nie obsługuje. Za to odpowiada agencja lub developer.
Kary umowne: bez nich SLA jest tylko deklaracją
SLA bez kar umownych to jak drogowskaz bez drogi - wskazuje kierunek, ale do niczego nie zobowiązuje. Wykonawca może dobrowolnie dotrzymywać standardów, ale nie ma żadnego realnego bodajźca.
W praktyce stosuje się kilka modeli kar:
Obniżenie faktury miesięcznej - najczęstszy model. Przykładowy zapis: „Za każde przekroczenie czasu naprawy błędu krytycznego o więcej niż 2 godziny, wynagrodzenie miesięczne ulega zmniejszeniu o 5%, jednak nie więcej niż 30% w ciągu jednego miesiąca.”
Kredyty czasowe - zamiast obniżki, klient dostaje dodatkowe godziny pracy do wykorzystania. Używane częściej przy umowach z dużym wolumenem godzin.
Odszkodowanie za przerwę w działaniu - rzadsze, stosowane głównie przy dużych sklepach, gdzie każda godzina przestoju ma mierzalną wartość.
Kara umowna nie może być wyższa niż faktyczna strata - taka klauzula byłaby nieegzekwowalna. Pamiętaj też, że jeśtem webdeveloperem, nie prawnikiem - ostateczne brzmienie klauzul kar umownych warto skonsultować z radcą prawnym, zwłaszcza przy większych kontraktach.
Czerwone flagi w umowach bez SLA
Na 120+ projektów, które zrealizowałem, wielokrotnie widziałem umowy, które wyglądały profesjonalnie, ale nie zabezpieczały klienta. Oto sformułowania, przy których powinienną/powinieneś zapalić się czerwona lampka:
Plusy
- "Czas reakcji: do 2 godzin w dni robocze" - konkretna liczba i zakres
- "Backup codzienny na oddzielnym serwerze, retencja 30 dni"
- "Odtworzenie z backupu w ciągu 4 godzin od zgłoszenia"
- "Kara umowna: 5% miesięcznego wynagrodzenia za każde przekroczenie"
- "Okno serwisowe: wt-czw 23:00-05:00"
Minusy
- "Reagujemy niezwłocznie" - bez konkretnej liczby godzin
- "Zapewniamy bezpieczeństwo strony" - bez opisu co to znaczy
- "W razie awarii odtworzymy stronę" - bez gwarancji czasu
- Brak jakiegokolwiek SLA lub załącznika o poziomie usług
- Kary umowne "do negocjacji" lub całkowita ich nieobecność
Brak SLA to brak odpowiedzialności - nie zła wola, ale fakt prawny. Jeśli umowa nie mówi, ile czasu ma wykonawca na naprawę, sąd uzna za akceptowalny „roztropny czas”, który może trwać tygodniami.
Jak negocjować SLA z agencją
Większość małych i średnich firm nie wie, że SLA można negocjować. Traktują podpisaną umowę jako coś stałego, bo tak agencja ją przedstawiła. Ale każdy wykonawca, który poważnie traktuje długoterminową współpracę, jest otwarty na rozmowę o warunkach.
Przed rozmową warto wiedzieć:
- Im wyższy pakiet miesięczny, tym lepsze warunki SLA można wynegocjować. Agencja oferująca podstawową opiekę za 300 zł/mc nie może obiecać takich samych parametrów co pakiet za 1 500 zł/mc.
- Powiedz jasno, co jest krytyczne dla Twojego biznesu: godziny szczytu (np. piatek 18:00-22:00 dla e-commerce), integracje (Przelewy24, BLIK, BaseLinker, Allegro), specyfika sezonu.
- Zapytaj o proces eskalacji - co się dzieje, jeśli osoba odpowiedzialna jest na urlopie?
- Zapytaj o test backupu - kiedy ostatnio wykonawca testował odtworzenie kopii na środowisku testowym?
Wedug cen rynkowych z początku 2026, pakiety opieki WordPress zaczynają się od około 160-300 zł/mc netto za podstawową konserwację, a profesjonalne pakiety z SLA dla e-commerce to 800-1 500 zł/mc netto. Więcej o wycenie znajdziesz w porównaniu kosztów opieki WordPress z kalkulatorem.
Przykłady realnych zapisów SLA
Poniżej kilka konkretnych sformułowań, które możesz użyć jako punkt wyjścia do negocjacji z agencją:
Czas reakcji:
> „Wykonawca potwierdza przyjęcie każdego zgłoszenia w czasie nie dłuższym niż: 1 godzina dla Priorytetu Krytycznego, 4 godziny dla Priorytetu Wysokiego, 1 dzień roboczy dla Priorytetu Standardowego. Potwierdzenie może być przesłane emailem lub wiadomością w systemie zgłoszeń.„
Czas naprawy:
> „Wykonawca dąży do usunięcia błędu w czasie nie dłuższym niż: 4 godziny dla Priorytetu Krytycznego, 24 godziny dla Priorytetu Wysokiego, 5 dni roboczych dla Priorytetu Standardowego. Czas naprawy liczony jest od momentu zgłoszenia, z wyłączeniem czasu oczekiwania na odpowiedź lub decyzję Zamawiającego.„
Backup:
> „Wykonawca zapewnia tworzenie kopii zapasowej całej strony (baza danych + pliki) minimum raz na dobę. Kopie przechowywane są na oddzielnym serwerze przez minimum 30 dni. Odtworzenie strony ze stanu z poprzedniej doby nastąpi w ciągu 4 godzin od zgłoszenia awarii.„
Szerzej o tym, co powinien obejmować cały pakiet opieki - poza SLA - opisalem w przewodniku po opiece technicznej WordPress. Jeśli dopiero rozważasz wybór wykonawcy, zajrzyj też do listy czerwonych flag przy taniej opiece - SLA to jeden z wskaźników, ale nie jedyny.
Jakie pytania zadać przed podpisaniem umowy
Zbierając to wszystko w praktyczny przewodnik dla osoby, która zaraz siada do rozmów z agencją:
Pytania do agencji przed podpisaniem SLA
- Jaki jest Wasz czas reakcji na błąd krytyczny (strona niedostępna)?
- Jaki jest czas naprawy dla błędu krytycznego?
- Gdzie przechowujecie kopie zapasowe i jak długo?
- W jakim czasie odtworzycie stronę z backupu?
- Kiedy ostatnio testowaliście odtworzenie kopii na środowisku testowym?
- Jakie są godziny okna serwisowego?
- Co się dzieje, jeśli odpowiedzialny developer jest nieosiągalny (urlop, choroba)?
- Jakie kary umowne przewiduje umowa za przekroczenie SLA?
- Czy SLA obejmuje również czas po stronie hostingów partnerów?
Jeśli agencja odpowie na większość pytań konkretnie - to dobry znak. Jeśli usyszysz „reagujemy szybko”, „zawsze jesteśmy dostępni” albo „to zależy od sytuacji” bez liczb - potraktuj to jako sygnał do głębszej rozmowy lub zmiany wyboru.
Opieka techniczna WordPress to usługa, za którą płacisz co miesiąc, żeby nie myśleć o stronie w nocy. SLA jest tym, co sprawia, że ta obietnica ma pokrycie w rzeczywistości. Więcej o tym, jak wygląda kompleksowa opieka techniczna WordPress w praktyce - zapraszam na stronę usługi.
Czas reakcji to okres od zgłoszenia problemu do pierwszego kontaktu wykonawcy - potwierdzenia, że zgłoszenie dotarło i ktoś się nim zajmuje. Czas naprawy to okres od zgłoszenia do pełnego rozwiązania problemu. Dobra umowa określa oba wskaźniki osobno dla różnych kategorii pilności. Najczęściej stosuje się procentowe obniżenie miesięcznego wynagrodzenia za każde przekroczenie czasu reakcji lub naprawy. Przykład: 5% rabatu od faktury za każde przekroczenie SLA dla błędu krytycznego, maksymalnie 30% w miesiącu. Okno serwisowe to przedział czasowy, w którym wykonawca może przeprowadzać aktualizacje, wdrożenia i prace konserwacyjne. Zazwyczaj ustala się je na noc lub weekend, żeby uniknąć przerw w dostępności podczas godzin szczytu. Hosting ma SLA dotyczące infrastruktury (99,9% uptime serwera), ale nie obejmuje Twojej aplikacji WordPress - błędów wtyczek, awarii po aktualizacji, hacków czy problemów z kodem. Umowa z agencją powinna precyzować odpowiedzialność po stronie aplikacji. Umowa powinna zawierać trzy parametry: częstotliwość tworzenia kopii (minimum raz dziennie), miejsce przechowywania (osobny serwer niż strona) oraz gwarantowany czas odtworzenia wyrażony w godzinach, np. „przywrócenie w ciągu 4 godzin od zgłoszenia”. Nie musi - może być załącznikiem do głównej umowy o świadczenie usług IT. Ważne, żeby był czytelny, miał własny numer wersji i datę obowiązywania oraz żeby obie strony go podpisały.Najczęstsze pytania
Czym różni się czas reakcji od czasu naprawy w umowie SLA?
Jakie kary umowne powinny być zapisane w SLA na opiekę WordPress?
Co to jest okno serwisowe w umowie SLA?
Czy hosting WordPress ma własne SLA i czy zastupuje ono umowę z agencją?
Jak powinna wyglądać gwarancja odtworzenia z backupu w SLA?
Czy umowa SLA na opiekę WordPress musi być oddzielnym dokumentem?
Potrzebujesz pomocy z projektem?
Robię strony WordPress i sklepy Shoper od 2500 zł. Partner Shoper, 120+ projektów.
- Odpowiedź w 24h
- Certyfikowany Partner Shoper
- 120+ zrealizowanych projektów
- Zgodność z RODO, pełna ochrona danych