Sentry to platforma do monitorowania błędów i wydajności aplikacji w czasie rzeczywistym. Ale ta definicja nic nie mówi o tym, dlaczego po wdrożeniu Sentry w trzech dużych projektach Next.js przestałem traktować logi serwera jako główne źródło informacji o problemach — i dlaczego uważam, że każdy projekt produkcyjny bez error trackingu to tykająca bomba.
Zanim przejdę do technikaliów — kontekst. Przez ostatnie dwa lata wdrożyłem Sentry w projektach od serwisu finansowego z 42 landing page'ami, przez sklep WooCommerce z headless frontem, po portal informacyjny z ponad 200 trasami. W każdym z tych projektów Sentry złapało błędy, o których nie wiedziałem — mimo że monitorowałem logi, testowałem ręcznie i miałem CI/CD z testami.
Problem jest prosty: użytkownicy nie zgłaszają błędów. Jeśli coś nie działa na jednym konkretnym modelu telefonu z Androidem 12 i przeglądarką Samsung Internet, użytkownik po prostu wychodzi. Nie pisze maila. Nie dzwoni. Po prostu znika — a Ty tracisz konwersję i nawet nie wiesz, że coś jest nie tak.
Czym dokładnie jest Sentry i jak działa
Sentry to usługa SaaS (z opcją self-hosted), która przechwytuje wyjątki, błędy i problemy wydajnościowe w Twojej aplikacji — zarówno po stronie klienta (przeglądarka), jak i serwera (Node.js, API routes, Server Components). Każdy przechwycony błąd trafia do dashboardu z pełnym kontekstem: stack trace, informacje o przeglądarce i systemie operacyjnym, breadcrumbs (co użytkownik robił przed błędem), a nawet nagranie sesji (Session Replay).
Kluczowa różnica między Sentry a zwykłymi logami: Sentry grupuje błędy w „issues". Jeśli ten sam TypeError wystąpi 300 razy u różnych użytkowników, widzisz jeden issue z liczbą wystąpień, nie 300 linii w logu. To zmienia sposób priorytetyzacji — widzisz od razu, co boli najbardziej.
Sentry obsługuje kilkadziesiąt platform i języków. W kontekście webowym najczęściej spotykamy się z SDK dla:
- JavaScript / TypeScript — przechwytywanie błędów w przeglądarce (uncaught exceptions, unhandled promise rejections)
- Node.js — błędy na serwerze, API routes, Server Components
- Next.js — dedykowany SDK łączący oba powyższe z instrumentacją App Routera
- React — Error Boundaries + component tracking
Dlaczego console.log i logi serwera to za mało
Słyszę to regularnie: „mamy logi na serwerze, więc monitoring błędów mamy ogarnięty". Z mojej praktyki wynika, że to złudzenie — i to niebezpieczne.
Po pierwsze: błędy klienckie nie trafiają do logów serwera. Jeśli JavaScript rzuca TypeError w przeglądarce użytkownika, Twój serwer tego nie zobaczy. A to właśnie błędy klienckie stanowią większość problemów wpływających na konwersję — zepsuty formularz, nieklikalny przycisk CTA, komponent który nie renderuje się na Safari iOS.
Po drugie: logi serwera to surowy strumień tekstu. Żeby znaleźć konkretny problem, musisz wiedzieć, czego szukasz. Sentry odwraca ten model — to narzędzie samo przychodzi do Ciebie z problemem, posortowanym po częstotliwości i wpływie na użytkowników.
Po trzecie: logi nie mają kontekstu użytkownika. Widzisz „TypeError: Cannot read properties of undefined (reading 'map')" — ale nie wiesz, czy to dotyczy jednego użytkownika czy tysiąca, na jakim urządzeniu wystąpił błąd, ani co użytkownik robił wcześniej. Sentry daje to wszystko w jednym widoku.
Wdrożenie Sentry w projekcie Next.js — krok po kroku
Sentry ma dedykowany wizard do Next.js, który konfiguruje SDK automatycznie. W praktyce wygląda to tak:
1. Instalacja i inicjalizacja:
npx @sentry/wizard@latest -i nextjs
Wizard tworzy trzy pliki konfiguracyjne: sentry.client.config.ts, sentry.server.config.ts i sentry.edge.config.ts — odpowiednio dla kodu klienckiego, serwerowego i edge runtime. Dodaje też instrumentation.ts z hookiem do Next.js i modyfikuje next.config.js, żeby podpiąć Sentry webpack plugin.
2. Source maps i nazwy wersji:
Żeby stack trace'y w Sentry pokazywały czytelny kod źródłowy (a nie zminifikowany bundle), Sentry automatycznie uploaduje source mapy podczas buildu. To kluczowe — bez tego widzisz a.map is not a function in chunk-3f2a.js:1:4832 zamiast konkretnej linii w Twoim kodzie.
3. Konfiguracja Error Boundary w React:
Sentry SDK dla React oferuje komponent Sentry.ErrorBoundary, który łapie błędy w drzewie React i wysyła je do Sentry z pełnym kontekstem komponentu. W Next.js App Router warto go umieścić w app/global-error.tsx:
'use client'
import * as Sentry from '@sentry/nextjs'
export default function GlobalError({ error }: { error: Error }) {
Sentry.captureException(error)
return (
<html><body>
<h2>Coś poszło nie tak</h2>
</body></html>
)
}4. Instrumentacja Server Components i API Routes:
W Next.js 14+ z App Routerem, Sentry automatycznie instrumentuje Server Components. Błędy w page.tsx, layout.tsx czy route.ts (API routes) są przechwytywane bez dodatkowej konfiguracji. Jeśli chcesz ręcznie raportować błąd (np. w try-catch), używasz Sentry.captureException(error).
Co Sentry łapie, czego nie złapiesz sam
Z moich projektów — konkretne przykłady błędów, które Sentry wyłapało, a których nie znalazłbym innymi metodami:
- Hydration mismatch na Safari iOS 15 — komponent renderował datę po stronie serwera w innym formacie niż po stronie klienta. Na Chrome działało. Na Safari — biały ekran. Sentry złapało to po 2 godzinach od deployu z pełnym stack trace'em i informacją o urządzeniu.
- CORS error w API route — edge case, który występował tylko gdy użytkownik miał ustawiony specyficzny nagłówek Accept-Language. 15 użytkowników dziennie trafiało na ten błąd — bez Sentry nigdy bym go nie znalazł.
- Memory leak w Server Component — Sentry Performance wychwycił, że jedna trasa odpowiada coraz wolniej z biegiem czasu. Okazało się, że zamykanie połączeń do cache'a nie działało prawidłowo przy ISR.
- Broken third-party script — zewnętrzny skrypt chatbota zaczął rzucać wyjątkami po aktualizacji. Nie nasza wina, ale nasz problem — użytkownicy widzieli błędy w konsoli, a formularz kontaktowy przestał działać.
Sentry Performance — monitoring wydajności
Sentry to nie tylko error tracking. Moduł Performance monitoruje wydajność aplikacji w sposób, który uzupełnia Lighthouse i Core Web Vitals z GSC.
Kluczowa różnica: Lighthouse mierzy syntetycznie (symulowane warunki, jeden URL na raz). Sentry Performance mierzy Real User Monitoring (RUM) — zbiera dane od prawdziwych użytkowników, na prawdziwych urządzeniach, w prawdziwych warunkach sieciowych.
