Kod odpowiedzi HTTP
ważność krytycznamierzonysposób http
Kod odpowiedzi serwera (200 OK, 5xx błąd, nieoczekiwany 3xx). Pierwsze źródło prawdy o dostępności aplikacji.
WIKI
artykuł z 16.09.2026 · źródeł 10Kod odpowiedzi HTTP (ang. HTTP status code) to parametr monitoringu stron internetowych, który rejestruje trzycyfrowy kod zwrócony przez serwer w odpowiedzi na żądanie sondy i na jego podstawie przypisuje stronie stan: poprawna odpowiedź (200 OK), błąd serwera (klasa 5xx), nieoczekiwane przekierowanie (klasa 3xx) albo odmowa dostępu lub brak zasobu (klasa 4xx) [1]. Kod z klasy 2xx nie gwarantuje jednak, że zwrócona treść jest poprawna [5].
Jak działa
Specyfikacja HTTP definiuje kod stanu jako trzycyfrową liczbę całkowitą, której pierwsza cyfra wyznacza klasę odpowiedzi [1]. Klas jest pięć: 1xx (informacyjne, żądanie odebrano i przetwarzanie trwa), 2xx (powodzenie), 3xx (przekierowanie, potrzebne jest dalsze działanie), 4xx (błąd klienta) oraz 5xx (serwer nie zdołał obsłużyć poprawnego żądania) [1] [4]. Klient, który nie rozpoznaje konkretnego kodu, powinien traktować go jak kod x00 z tej samej klasy [1].
Między sondą a aplikacją często działa pośrednik: sieć CDN, odwrotne proxy lub bramka. Kod może wtedy pochodzić z innej warstwy niż sama aplikacja. Według RFC 9110 kod 502 oznacza, że brama lub proxy otrzymała nieprawidłową odpowiedź od serwera, do którego przekazała żądanie, a 504, że nie otrzymała odpowiedzi w wymaganym czasie [1].
Sam kod nie wystarcza do oceny, czy strona działa. Dokumentacja WordPressa opisuje sytuację, w której błędy PHP lub bazy danych kończą się pustym ekranem bez żadnej informacji, nazywanym białym ekranem śmierci (WSOD) [6]. Google oznacza jako „soft 404” adresy, które zwracają kod z klasy 2xx, a ich treść wskazuje na błąd, na przykład pustą stronę lub komunikat o błędzie; kod 2xx nie gwarantuje też indeksowania [5]. Z tego powodu kod odpowiedzi uzupełnia się osobnym parametrem weryfikującym treść strony.
Standardy i specyfikacje
Znaczenie kodów definiuje RFC 9110 (HTTP Semantics), a oficjalny wykaz prowadzi IANA w rejestrze „Hypertext Transfer Protocol (HTTP) Status Code Registry”; nowe wpisy przechodzą procedurę IETF Review [3]. Kod 429 Too Many Requests wprowadził RFC 6585 z kwietnia 2012 roku. Oznacza on, że użytkownik wysłał zbyt wiele żądań w określonym czasie, a odpowiedź może zawierać nagłówek Retry-After; specyfikacja nie określa, jak serwer identyfikuje użytkownika ani jak liczy żądania [2].
Z punktu widzenia monitoringu najważniejsze są następujące kody:
- 200 OK: treść odpowiedzi jest reprezentacją żądanego zasobu [1].
- 301 i 308: przekierowania trwałe; 302 i 307: tymczasowe. Kody 307 i 308 zachowują metodę żądania [1]. Roboty Google podążają za najwyżej 10 kolejnymi przekierowaniami, trwałe traktują jako silny sygnał, a tymczasowe jako słaby [5].
- 403 Forbidden: serwer odmawia obsłużenia żądania; 404 Not Found: serwer nie znalazł zasobu [1]. Serwer może też odpowiedzieć 404 zamiast 403, aby ukryć istnienie zasobu [4].
- 500 Internal Server Error: ogólny błąd serwera [1].
- 502 Bad Gateway i 504 Gateway Timeout: błędy pośrednika opisane wyżej [1].
- 503 Service Unavailable: chwilowe przeciążenie lub planowana konserwacja. Serwer może wysłać
Retry-Afterz datą HTTP albo liczbą sekund [1]. Takich odpowiedzi zwykle nie należy buforować [4].
Cloudflare zwraca własne kody z zakresu 52x, między innymi 520 (serwer WWW zwrócił nieznany błąd), 521 (serwer WWW nie działa), 522 (przekroczony czas połączenia), 524 (przekroczony czas oczekiwania), 525 (nieudane uzgadnianie SSL) i 526 (nieprawidłowy certyfikat SSL) [9]. Nie są to kody standardowe: w rejestrze IANA zakres 512–599 pozostaje nieprzydzielony [3], więc klient, który ich nie zna, potraktuje je jak 500 [1].
Zagrożenia i skutki
Awaria aplikacji. Po błędzie krytycznym PHP WordPress wyświetla komunikat „There has been a critical error on this website” i kończy działanie funkcją wp_die() z kodem 500. Gdy witryna przechodzi w tryb odzyskiwania (recovery mode), komunikat o tym informuje, a w instalacji z jedną witryną odsyła do skrzynki e-mail administratora [7]. Wśród przyczyn błędów krytycznych dokumentacja wymienia konflikty wtyczek, niezgodność motywu lub wersji PHP, limity pamięci i uszkodzone pliki, a jako najczęstszą przyczynę błędu „Internal Server Error” uszkodzony plik .htaccess [6].
Konserwacja podczas aktualizacji. Po aktualizacji odwiedzający mogą zobaczyć komunikat „Briefly unavailable for scheduled maintenance”, który pozostaje, gdy plik .maintenance nie zostanie usunięty z katalogu głównego witryny [6]. Funkcja wp_maintenance() wysyła ten komunikat z kodem 503 i nagłówkiem Retry-After: 600 [8].
Widoczność w wyszukiwarce. Kody 5xx oraz 429 powodują, że roboty Google tymczasowo spowalniają pobieranie stron; kod 429 jest traktowany jako sygnał przeciążenia serwera, czyli błąd serwera. Adresy, które trwale zwracają błąd serwera, są usuwane z indeksu, a treści z adresów zwracających kody 4xx Google nie wykorzystuje [5].
Fałszywe alarmy. Zapory aplikacyjne (WAF) odmawiają dostępu żądaniom pasującym do reguł, co może dotyczyć także sond monitoringu. W Cloudflare akcja Block zwraca domyślnie kod 403, a w regułach ograniczania liczby żądań kod 429; od planu Pro kod odpowiedzi można zmienić. Wyzwanie JavaScript ma zatrzymywać boty, podczas gdy przeglądarki mogą je rozwiązać automatycznie [10]. Kod 403 lub 429 otrzymany przez sondę nie oznacza więc sam w sobie, że strona jest niedostępna dla odwiedzających.
Przykłady
| Kod | Znaczenie wg RFC | Typowa przyczyna na stronie WordPress |
|---|---|---|
| 200 | żądanie obsłużone, treść reprezentuje zasób [1] | strona działa; treść może mimo to wskazywać błąd (soft 404) [5] |
| 301 / 308 | przekierowanie trwałe [1] | trwałe przeniesienie adresu, dla Google silny sygnał [5] |
| 302 / 307 | przekierowanie tymczasowe [1] | tymczasowe przeniesienie adresu, dla Google słaby sygnał [5] |
| 403 | serwer odmawia obsłużenia żądania [1] | blokada żądania przez WAF (akcja Block) [10] |
| 404 | serwer nie znalazł zasobu [1] | adres nie istnieje albo serwer ukrywa zasób zamiast 403 [4] |
| 429 | zbyt wiele żądań w określonym czasie [2] | reguła ograniczania liczby żądań w WAF [10] |
| 500 | ogólny błąd serwera [1] | błąd krytyczny PHP [7], uszkodzony .htaccess [6] |
| 502 | pośrednik otrzymał nieprawidłową odpowiedź [1] | serwer za proxy lub CDN zwrócił niepoprawną odpowiedź [1] |
| 503 | chwilowe przeciążenie lub konserwacja [1] | aktualizacja z plikiem .maintenance [6], Retry-After: 600 [8] |
| 504 | pośrednik nie otrzymał odpowiedzi na czas [1] | serwer za proxy lub CDN odpowiada zbyt wolno [1] |
| 520–526 | brak w RFC 9110 i w rejestrze IANA [3] | kody Cloudflare, np. serwer WWW nie działa lub przekroczony czas [9] |
- [1] RFC 9110 — HTTP Semantics · IETF
- [2] RFC 6585 — Additional HTTP Status Codes · IETF
- [3] Hypertext Transfer Protocol (HTTP) Status Code Registry · IANA
- [4] HTTP response status codes · MDN Web Docs (Mozilla)
- [5] How HTTP status codes affect Google's crawlers · Google Search Central
- [6] Common WordPress Errors · WordPress.org
- [7] WP_Fatal_Error_Handler::display_default_error_template() · WordPress Developer Resources
- [8] wp_maintenance() · WordPress Developer Resources
- [9] Cloudflare 5xx errors · Cloudflare
- [10] Actions — Rules language · Cloudflare
STATS
wyniki z systemu · tylko liczby zbiorcze- Stron zmierzonych
- 270w ostatnim dniu pomiaru
- OK
- 447odczytów
- Fail
- 35odczytów
- Nie dało się sprawdzić
- 32timeout, blokada, limit zapytań
- Udział fail
- 7,3%bez „nie dało się”
- Stron łącznie
- 272choć jeden odczyt
- OK
- 70005odczytów
- Fail
- 5663odczytów
- Nie dało się sprawdzić
- 2394timeout, blokada, limit zapytań
- Udział fail
- 7,5%bez „nie dało się”
| Dzień | fail | nie dało się sprawdzić | ok |
|---|---|---|---|
| 08.10.2026 | 141 odczytów | 59 odczytów | 1582 odczyty |
| 09.10.2026 | 141 odczytów | 60 odczytów | 1581 odczytów |
| 10.10.2026 | 200 odczytów | 58 odczytów | 1524 odczyty |
| 11.10.2026 | 53 odczyty | 91 odczytów | 1638 odczytów |
| 12.10.2026 | 57 odczytów | 89 odczytów | 1636 odczytów |
| 13.10.2026 | 55 odczytów | 90 odczytów | 1637 odczytów |
| 14.10.2026 | 106 odczytów | 74 odczyty | 1602 odczyty |
| 15.10.2026 | 134 odczyty | 59 odczytów | 1589 odczytów |
| 16.10.2026 | 139 odczytów | 60 odczytów | 1583 odczyty |
| 17.10.2026 | 132 odczyty | 60 odczytów | 1590 odczytów |
| 18.10.2026 | 142 odczyty | 58 odczytów | 1582 odczyty |
| 19.10.2026 | 132 odczyty | 59 odczytów | 1591 odczytów |
| 20.10.2026 | 140 odczytów | 61 odczytów | 1581 odczytów |
| 21.10.2026 | 87 odczytów | 78 odczytów | 1626 odczytów |
| 22.10.2026 | 75 odczytów | 87 odczytów | 1620 odczytów |
| 23.10.2026 | 55 odczytów | 88 odczytów | 1639 odczytów |
| 24.10.2026 | 62 odczyty | 86 odczytów | 1634 odczyty |
| 25.10.2026 | 104 odczyty | 73 odczyty | 1605 odczytów |
| 26.10.2026 | 136 odczytów | 60 odczytów | 1586 odczytów |
| 27.10.2026 | 155 odczytów | 57 odczytów | 1570 odczytów |
| 28.10.2026 | 151 odczytów | 61 odczytów | 1570 odczytów |
| 29.10.2026 | 136 odczytów | 61 odczytów | 1590 odczytów |
| 30.10.2026 | 145 odczytów | 58 odczytów | 1675 odczytów |
| 31.10.2026 | 144 odczyty | 58 odczytów | 1676 odczytów |
| 01.11.2026 | 92 odczyty | 75 odczytów | 1711 odczytów |
| 02.11.2026 | 96 odczytów | 83 odczyty | 1758 odczytów |
| 03.11.2026 | 164 odczyty | 72 odczyty | 1742 odczyty |
| 04.11.2026 | 195 odczytów | 91 odczytów | 1840 odczytów |
| 05.11.2026 | 280 odczytów | 53 odczyty | 1699 odczytów |
| 06.11.2026 | 35 odczytów | 32 odczyty | 447 odczytów |
- Otwarte teraz
- 56stron: 56 · w okresie łaski: 6
- Nowe w ostatnim dniu
- 606.11.2026
- Otwarte od początku
- 721stron: 243
- Zamknięte
- 659od początku
- Mediana trwania
- 6 h 0 minod wykrycia do zamknięcia
| Ustalenie | Skutek | Otwarte teraz | Łącznie | Zamknięte |
|---|---|---|---|---|
| Odpowiedź HTTP http | strona nie odpowiada | 56 | 721 | 659 |
| Dzień | nowe ustalenia |
|---|---|
| 08.10.2026 | 6 ustaleń |
| 09.10.2026 | 3 ustalenia |
| 10.10.2026 | 81 ustaleń |
| 11.10.2026 | 3 ustalenia |
| 12.10.2026 | 7 ustaleń |
| 13.10.2026 | 4 ustalenia |
| 14.10.2026 | 20 ustaleń |
| 15.10.2026 | 5 ustaleń |
| 16.10.2026 | 7 ustaleń |
| 17.10.2026 | 2 ustalenia |
| 18.10.2026 | 12 ustaleń |
| 19.10.2026 | 2 ustalenia |
| 20.10.2026 | 12 ustaleń |
| 21.10.2026 | 11 ustaleń |
| 22.10.2026 | 16 ustaleń |
| 23.10.2026 | 2 ustalenia |
| 24.10.2026 | 10 ustaleń |
| 25.10.2026 | 16 ustaleń |
| 26.10.2026 | 8 ustaleń |
| 27.10.2026 | 8 ustaleń |
| 28.10.2026 | 1 ustalenie |
| 29.10.2026 | 2 ustalenia |
| 30.10.2026 | 7 ustaleń |
| 31.10.2026 | 5 ustaleń |
| 01.11.2026 | 4 ustalenia |
| 02.11.2026 | 15 ustaleń |
| 03.11.2026 | 11 ustaleń |
| 04.11.2026 | 12 ustaleń |
| 05.11.2026 | 105 ustaleń |
| 06.11.2026 | 6 ustaleń |
- Przebiegów
- 60sposób http
- W 30 dni
- 0przebiegów
- Ostatni
- 19.09.2026start przebiegu
- Stron w przebiegach
- 20461 przebiegów bez liczby stron
CARD
karta z kodu CREATO_PING, odczyt 22.09.2026Jak ten parametr trafia do ClickUpa: wynik sondy to linia w subtasku 2. Pomiar, a usterka, którą otwiera — linia w subtasku 1. Podsumowanie (z identyfikatorem CWE i kategorią OWASP), skąd liczy się wskaźnik zagrożenia i status strony. Projekcja z bazy skanera odświeża oba subtaski co godzinę. Do 22.09 każde ustalenie dostawało własny subtask i status ze starego słownika (PODATNA, WARNING…) — te słowa zostały jeszcze w części opisów pomiaru niżej jako język wewnętrzny sond.
| Obszar i ważność | Dostępność · krytyczna (D03) |
|---|---|
| Workflow i częstotliwość | creato_ping_avail_v2 działa na LAB247Skaner 2.0, rytm „dostepnosc”: premium co 15 min, reszta co 3–12 h · Dawny workflow n8n avail_v2; od 20.09 te same sondy w rytmie kohort skanera. Sposób ssl daje odczyt ssl_expiry (dni do wygaśnięcia certyfikatu); odczyty trafiają do check_results. |
| Sonda i helper | sposób http · CREATO_PING/helpers/http_check.py |
| Testy |
|
| Typ wyniku | enum: ok / fail / timeout + kod HTTP, rozmiar odpowiedzi, adres końcowy |
| Jednostka | kod HTTP; czas w ms |
| Próg i reguła | Timeout odpowiedzi 5,0 s, połączenia 2,0 s. Reguła kodu: 200 ≤ kod < 400. |
| Gdzie leżą pokrętła | CREATO_PING/helpers/http_check.py → _classifyCREATO_PING/helpers/common.py → BLOCK_LIKE_STATUSESCREATO_PING/helpers/config.py → TIMEOUTS["http"] |
| Retencja odczytów | Surowy pomiar jako NIEZMIENNY wiersz tabeli `odczyty` w bazie skanera (wejście, wyjście, dowody, sha karty sondy i helpera, commit kodu) — trigger odrzuca każdą zmianę. Okno retencji z kohorty: 90 dni premium, 30 dni reszta; poza oknem zostają odczyty z werdyktem problemu, akcją albo etykietą, bo replay reguł ich potrzebuje (`skaner/retencja.py`). Spłaszczony wynik jedzie dodatkowo do tabeli `check_results` bazy LAB247 (skrzynka `state/checks_outbox` → timer co 10 min); tej tabeli kod LAB247 nie czyści. |
| Karta przepisana z | CREATO_PING/helpers/http_check.py · CREATO_PING/helpers/common.py · CREATO_PING/helpers/config.py · CREATO_PING/helpers/site_params.py · CREATO_PING/skaner/usterki.toml · CREATO_PING/skaner/ocena.py · odczyt 22.09.2026 |
http: bramka polityki otwarta (gate=true) → sprawa w skanerze → Strona nie oddaje poprawnej odpowiedzi (5xx/4xx/timeout) — waga 4 → ocena 7–8 (pomarańczowy), status strony „wysoki”, dopóki sprawa jest otwarta. Okres łaski: 1. porażka zakłada sprawę ze statusem IN PROGRESS, której wskaźnik NIE liczy (`ocena.py` pomija sprawy niepotwierdzone), 2. porażka z rzędu potwierdza sprawę i dopiero wtedy usterka wchodzi do oceny. Pierwszy odczyt ok zamyka sprawę. http jest sprawdzeniem krytycznym. Druga próba z UA przeglądarki rozstrzyga wcześniej: 2xx albo 3xx po niej = wynik ok z flagą ua_fallback, więc blokada WAF nie zakłada sprawy.
| Kod | Finding | Severity | Pewność | Skutek | Finding / alarm | Waga → ocena | Co zrobić |
|---|---|---|---|---|---|---|---|
| D03.01 | Odpowiedź HTTPhttp | Wysoka | Ewidentne | strona nie odpowiada | tak / tak | waga 4 → ocena 7–8 (pomarańczowy) | Sprawdź logi serwera i PHP, ostatnie aktualizacje wtyczek. |
| D03.02 | Błąd aplikacji widoczny z zewnątrzapp_error | Średnia | Ewidentne | usterka niekrytyczna | tak / nie | waga 2 → ocena 3–4 (niebieski) | Sprawdź log błędów PHP i wersję PHP na hostingu. |
| Kod i klucz | D03.01 · http · w tabeli typów |
|---|---|
| Co znaczy | Serwer zwraca błąd (5xx, 404) lub nie odpowiada. |
| Kiedy powstaje | GET na https://domena/ z przekierowaniami (maks. 5). Status ok dla kodów 200–399. Dla 4xx i 5xx fail, ale przy 403/406/415/429/451 Check ponawia z UA przeglądarki i daje ok, jeśli ponowienie zwróci kod poniżej 400. Wyjątek to fail, przekroczenie 5,5 s to timeout.Typ krytyczny. |
| Severity · pewność | Wysoka · Ewidentne |
| Skutek dla strony | strona nie odpowiada · zakłada Finding · alarm tak |
| Waga → ocena | waga 4 → ocena 7–8 (pomarańczowy) |
| Klasyfikacja | MITRE ATT&CK 19.2: T1499 Endpoint Denial of Service (skutek)OCSF 1.9.0: poza klasami Findingu |
| Rekord OCSF | finding_info.analytic.uid = "D03.01" · analytic.name = "http" · finding_info.types = ["D03 Kod odpowiedzi HTTP"] |
| Co zrobić | Sprawdź logi serwera i PHP, ostatnie aktualizacje wtyczek. |
| Wersje typu |
|
| Kod i klucz | D03.02 · app_error · w tabeli typów |
|---|---|
| Co znaczy | Strona odpowiada, ale coś w niej nie działa: fatal PHP, wymagana wersja PHP wyższa niż na serwerze, padające zadania cykliczne. Dziś zgłasza go audyt AI. |
| Kiedy powstaje | Nie emitowany przez żaden kod: brak finding_type app_error w helpers/, skaner/*.py, sondy/, tools/ ani wp-plugin/. Istnieje tylko jako wpis w polityce, katalogu usterek (skaner/usterki.toml:179), standardy.toml, zjawiska.toml i przypadku testowym reguł.nie emitowany: tylko wpis w polityce/katalogu (dane z ręcznego audytu AI). |
| Severity · pewność | Średnia · Ewidentne |
| Skutek dla strony | usterka niekrytyczna · zakłada Finding · alarm nie |
| Waga → ocena | waga 2 → ocena 3–4 (niebieski) |
| Klasyfikacja | OCSF 1.9.0: poza klasami Findingu |
| Rekord OCSF | finding_info.analytic.uid = "D03.02" · analytic.name = "app_error" · finding_info.types = ["D03 Kod odpowiedzi HTTP"] |
| Co zrobić | Sprawdź log błędów PHP i wersję PHP na hostingu. |
| Wersje typu |
|
LOOP
pętli: 3Trafności jeszcze nie liczymy: zamknięcie subtaska nie niesie dziś werdyktu (prawdziwy / fałszywy / nie dało się sprawdzić). Cztery liczby pojawią się, gdy każde zamknięcie dostanie werdykt — to warunek startu pętli 1.
Sygnał: Strony za WAF-em albo wtyczką bezpieczeństwa zwracały sondzie 403/429, a działały dla ludzi — fałszywe DOWN. · dotyczy też: Weryfikacja treści, Przekierowanie HTTP → HTTPS
- 1. Zbiórkaręcznieodczyt z nocnego skanu, bez zapisu per strona
- 2. Werdyktręcznieczłowiek potwierdził, że strona działa w przeglądarce
- 3. Miarabrakliczników trafności wtedy nie było
- 4. Kartabrakkarta parametru powstała 2026-09-16
- 5. Zmianazrobionedruga próba z UA przeglądarki
- 6. Replaybrakbrak zapisanych odczytów do replayu
| Data | Zmiana | Powód | Wpływ na system | Commit · replay |
|---|---|---|---|---|
| 2026-07-19 | Przy kodzie 403, 406, 415, 429 albo 451 sprawdzenie ponawia żądanie z UA przeglądarki; 2xx/3xx za drugim razem = ok (w przekierowaniu: adres końcowy na https).helpers/common.py · helpers/http_check.py · helpers/content_check.py · helpers/redirect_check.py | Blokada robotów na poziomie aplikacji nie jest niedostępnością strony. | cały system Ta sama reguła obowiązuje w weryfikacji treści — oba sprawdzenia czytają BLOCK_LIKE_STATUSES z common.py. | 343b699bez replayubez zapisu zatwierdzenia |
Sygnał: Strona wisiała na DOWN, choć działała: hosting klienta zbanował IP serwera monitoringu (SYN porzucany, nie odrzucany) po serii automatycznych odpytań. · dotyczy też: Połączenie TCP, SSL: ważność certyfikatu
- 1. Zbiórkaręcznieodczyt z nocnego skanu, bez zapisu per strona
- 2. Werdyktręczniedostępność potwierdzona z innych lokalizacji
- 3. Miarabrakliczników trafności wtedy nie było
- 4. Kartabrakkarta parametru powstała 2026-09-16
- 5. Zmianazrobionezewnętrzny cross-check i nowy status strony
- 6. Replaybrakbrak zapisanych odczytów do replayu
| Data | Zmiana | Powód | Wpływ na system | Commit · replay |
|---|---|---|---|---|
| 2026-07-19 | Timeout TCP/HTTP z naszego serwera sprawdzany z zewnątrz; odpowiedź z innych lokalizacji = status BLOKADA zamiast DOWN.helpers/network_block_check.py · helpers/site_params.py | Blokada sieciowa monitoringu to inny mechanizm niż blokada UA — działa poniżej HTTP. | cały system Nowy status strony w kolejności pierwszeństwa, nad DOWN — zmienia status każdej strony, nie tylko tego parametru. | 8c0c0c6bez replayubez zapisu zatwierdzenia |
Sygnał: Adres bez www odpowiadał 200, a forma z www miała certyfikat samopodpisany — silnik eskalował to do DOWN. · dotyczy też: Połączenie TCP, Rozwiązywanie DNS, SSL: ważność certyfikatu, Przekierowanie www ↔ bez www
- 1. Zbiórkaręcznieodczyt z nocnego skanu, bez zapisu per strona
- 2. Werdyktręcznieużytkownicy widzą sprawną stronę, więc alarm był fałszywy
- 3. Miarabrakliczników trafności wtedy nie było
- 4. Kartabrakkarta parametru powstała 2026-09-16
- 5. Zmianazrobionesprawdzenie częściowej dostępności i status CONFIG
- 6. Replaybrakbrak zapisanych odczytów do replayu
| Data | Zmiana | Powód | Wpływ na system | Commit · replay |
|---|---|---|---|---|
| 2026-08-04 | Częściowa dostępność (jedna forma 200, druga zepsuta) daje status CONFIG, który bije DOWN.helpers/site_params.py · helpers/partial_availability_check.py | Błąd konfiguracji do naprawy to nie awaria; realny DOWN zostaje, gdy nie odpowiada żadna forma. | cały system Nowy status strony nad DOWN; dotyczy wszystkich sprawdzeń krytycznych (tcp, dns, http, ssl). | 091e318bez replayubez zapisu zatwierdzenia |