Błąd 500 w aplikacji webowej - przyczyny i sposoby rozwiązania

Błąd HTTP 500 Internal Server Error to ogólny błąd serwera — coś poszło źle po stronie serwera, ale serwer nie wie, jak to dokładnie opisać. To komunikat z kategorii „awaria po naszej stronie”. W odróżnieniu od błędów 4xx (problem po stronie klienta — zły URL, brak uprawnień), 500 wskazuje na problem po stronie serwera. Klasyczne przyczyny — niezłapany wyjątek w kodzie aplikacji, błąd połączenia z bazą danych, brak pamięci, przekroczenie limitu CPU, błąd konfiguracji serwera, błąd w middleware (PHP-FPM, Node.js process).

Ścieżka diagnozy:

• logi serwera — error_log Apache lub Nginx, logi PHP-FPM, output Node.js: tam zwykle czeka stack trace z konkretną przyczyną,
• logi aplikacji — storage/logs Laravela, Sentry, Datadog,
• monitoring zasobów — CPU, pamięć, dysk: może serwer się po prostu przeciąża,
• ostatnie wdrożenia — jeśli 500 zaczęły się po deployu, rollback bywa najszybszym ratunkiem,
• baza danych — czy w ogóle jest osiągalna,
• usługi zewnętrzne — czy API, z których korzystasz, odpowiadają.

Lista podejrzanych:

• niezłapane wyjątki — null, niezdefiniowana zmienna, niezgodność typów,
• błędy SQL — timeouty, deadlocki, brak indeksów,
• brak pamięci — przekroczony memory limit, klasyka PHP,
• przekroczony maksymalny czas wykonania,
• błąd konfiguracji — zła ścieżka, brak uprawnień,
• awaria zewnętrznego API — nieosiągalny Stripe, PayPal czy Twilio,
• warstwa cache — leżący Redis, uszkodzony memcached,
• felerny deploy — nowa wersja źle wdrożona,
• race conditions — rzadkie i najtrudniejsze do odtworzenia.

Profilaktyka:

• porządna obsługa błędów — try-catch w miejscach krytycznych i łagodna degradacja zamiast wywracania całej strony,
• monitoring z alertami — Sentry, Datadog, New Relic: powiadomienie w minutę, nie od klienta,
• endpointy health check — regularna kontrola żywotności aplikacji,
• bezpieczne wdrożenia — blue-green i canary ograniczają zasięg ewentualnej wpadki,
• testy obciążeniowe — jak aplikacja zachowuje się pod ruchem,
• planowanie pojemności — czy infrastruktura udźwignie spodziewany szczyt,
• code review — drugie oczy łapią błędy,
• testy automatyczne — jednostkowe, integracyjne i E2E zatrzymują błędy przed produkcją.

Domyślnie — strona z technicznym komunikatem (Apache default error page, Nginx default). Klasycznie wygląda nieprofesjonalnie. Lepsza praktyka — custom 500 error page z marką firmy, przyjaznym komunikatem („Coś poszło nie tak, próbujemy to naprawić”), linkami do support/contact, opcjonalnie unique error ID (które klient może podać przy zgłaszaniu problemu). Plus monitoring (gdy 500 wzrasta, alerty do developerów). Plus rate limit dla błędów (nie wysyłaj 1000 alertów Sentry dla tego samego błędu — używaj fingerprinting). Profesjonalna obsługa błędów to różnica między „awaria, wszyscy są w panice” a „awaria, zespół to monitoruje i naprawia”.