SLA utrzymania strony WWWczas reakcji, monitoring i pakiet opieki 2026

TL;DR

SLA to nie PDF na półkę — to umowa operacyjna, która mówi, w ile godzin reagujemy na awarię formularza, a w ile na kosmetyczną poprawkę CSS. Dobre SLA dla strony firmowej łączy klasy priorytetów (P1–P4), monitoring uptime, backupy aplikacji i bazę w Branchly oraz jasny kanał zgłoszeń. Poniżej model SLA stosowany w pakiecie opieki DevStudio.it na hostingu DevStudioIT Cloud — z tabelami czasów reakcji i zakresem prac.

Dla kogo

• Właścicieli stron korporacyjnych po wdrożeniu, którzy nie mają wewnętrznego DevOps
• Firm porównujących „hosting za 50 zł” z managed care
• CTO i office managerów negocjujących umowę utrzymania z software house
• Każdego, kto dowiedział się o padnięciu strony od klienta, nie od monitoringu

Fraza (SEO)

sla utrzymanie strony www, czas reakcji awaria strony, monitoring strony firmowej, pakiet opieki strona internetowa 2026

Czym SLA różni się od „gwarancji” i od hostingu

Hosting to infrastruktura: serwer, SSL, deploy, transfer. Utrzymanie (maintenance) to reakcja na zdarzenia, aktualizacje, poprawki i rozwój w małym zakresie. SLA (Service Level Agreement) definiuje mierzalne zobowiązania: czas reakcji, czas przywrócenia usługi (RTO), dostępność (uptime) i wyłączenia (np. planowane okno maintenance w niedzielę 02:00–04:00).

Bez SLA masz dobre intencje w mailu „odpiszemy jak będziemy mogli”. Z SLA masz:

• Priorytet zgłoszenia przypisany w 15 minut
• Eskalację, gdy P1 nie ruszyło w 1 godzinę
• Raport miesięczny: uptime, incydenty, wykonane aktualizacje

Klasy priorytetów — przykładowy model

Godziny robocze: pn–pt 9:00–17:00 CET; P1 poza godzinami — best effort + dopłata lub rozszerzone SLA 24/7 dla e-commerce.

Reakcja ≠ naprawa. SLA powinno mówić wprost: „potwierdzimy i zdiagnozujemy w X”, „przywrócimy usługę lub obejście w Y”.

Monitoring — co mierzyć na DevStudioIT Cloud

Strona na DevStudioIT Cloud (devstudioit.cloud) nie kończy odpowiedzialności na „działa u mnie”. Pakiet opieki obejmuje:

• HTTP check co 1–5 min (GET /, oczekiwany 200)
• SSL expiry alert 14 dni przed wygaśnięciem
• Formularz syntetyczny — test POST co 24 h (lead testowy + alert jeśli 4xx/5xx)
• Core Web Vitals — trend LCP/INP w CrUX lub RUM (nie tylko Lighthouse raz na rok)
• Logi aplikacji — spike 500, rate limit przekroczony

Dane biznesowe (leady, zamówienia) siedzą w Branchly (branchly.cloud) — osobny monitoring backupów DB i connection pool. Awaria bazy ≠ awaria frontu; SLA powinno rozróżniać warstwy.

Przykład alertu w pipeline (pseudokod):

# monitoring.yml — fragment
checks:
  - name: homepage
    url: https://example.com/
    interval: 300s
    alert_after: 2 failures
    notify: [email, slack]
  - name: contact-form
    type: synthetic
    schedule: "0 8 * * *"
    post: /api/submissions
    expect_status: 201

Backupy i RTO/RPO

SLA bez backupów to iluzja. Standard w pakiecie opieki:

RTO (Recovery Time Objective): przywrócenie produkcji z backupu w 4–8 h dla P1. Procedura: rollback deploy w panelu Cloud → jeśli fail, restore DB snapshot w Branchly → smoke test formularza.

Klient dostaje runbook jednostronicowy: kogo dzwonić, co podać (URL, screenshot, czas), numer ticketu.

Zakres prac w pakiecie opieki vs poza SLA

W cenie utrzymania (typowo):

• Aktualizacje patchy bezpieczeństwa Node/Next.js po QA
• Monitoring i reakcja wg priorytetów
• Drobne poprawki bugów w istniejącym kodzie (limit godzin/mies.)
• Wsparcie DNS przy przenosinach domeny

Poza SLA / osobna wycena:

• Nowe podstrony, redesign sekcji
• Integracje CRM od zera
• Kampanie landingowe ad hoc
• Audyt SEO treści

Granica musi być w umowie — inaczej każde „dodajcie slider” jedzie na ticket P4 lub wycenę change request.

Kanał zgłoszeń i komunikacja

Jeden kanał: ticket (email na support@ z auto-ticketem) lub portal klienta. WhatsApp „do kolegi developera” nie jest SLA.

Każde zgłoszenie dostaje:

• ID ticketu
• Priorytet (może być skorygowany po diagnozie)
• ETA następnej aktualizacji

Przy P1 — update co 60 min do czasu przywrócenia. Przy P3 — wystarczy mail zamknięcia.

KPI miesięczne — raport dla klienta

Raport SLA co miesiąc (PDF lub mail):

• Uptime % (cel 99,9% dla strony marketingowej)
• Lista incydentów z czasem reakcji i MTTR
• Wykonane aktualizacje (Next.js, zależności npm)
• Godziny dev wykorzystane / pozostałe z pakietu
• Rekomendacje (np. „Node 22 EOL za 8 miesięcy — zaplanuj upgrade”)

Transparentność buduje zaufanie lepiej niż obietnica „nielimitowane wsparcie”.

FAQ

Czy SLA gwarantuje 100% uptime?

Nie — realistyczny cel to 99,9% (ok. 43 min przestoju/miesiąc). Wyjątki: force majeure, atak DDoS wymagający providera, planowane okno maintenance ogłoszone 48 h wcześniej.

Co jeśli incydent wynika z wtyczki dodanej przez klienta?

SLA obejmuje stack dostarczony przez DevStudio.it. Nieautoryzowane zmiany w produkcji (wklejony skrypt GTM, plugin WP na stagingu wrzucony na prod) — reakcja P1, naprawa może być chargeback.

Czy monitoring wystarczy bez opieki?

Monitoring bez człowieka to tylko mail o 3 w nocy. Opieka łączy alert z diagnozą i rollbackiem na DevStudioIT Cloud.

Jak długa umowa SLA?

Minimum 12 miesięcy po launchu — pierwsze kwartały generują najwięcej drobnych poprawek po feedbacku użytkowników.

CTA

Potrzebujesz strony z hostingiem, monitoringiem i jasnym SLA zamiast „zadzwoń jak coś padnie”?

• Porozmawiajmy o pakiecie opieki — dopasujemy priorytety i godziny reakcji
• Infrastruktura DevStudioIT Cloud — hosting, Branchly, utrzymanie w jednym ekosystemie