Miért más egy Next.js oldalt monitorozni
A Next.js egyszerre három dolog: szerver-renderelt HTML, statikus generált oldalak (SSG/ISR), és kliens-oldali React app. Ez a háromféle viselkedés három különböző hibalehetőséget hoz magával, és egy egyszerű "200-as válasz = minden rendben" check sokszor nem fogja meg, ha valami eltört.
A leggyakoribb néma hibák:
- A build sikeresen lefutott, de egy ISR oldal
revalidatehibára fut és stale tartalmat ad vissza. - Egy API route 500-asra dől egy DB connection hiba miatt, de a frontend oldalak még működnek.
- Egy middleware dob egy
Error-t, így minden kérés 500-as lesz, de a Vercel deploy oldala UP-ot mutat. - A client-side hidratáció elhasal egy hiányzó env var miatt, így a látogató fehér képernyőt lát, de a HTML 200-as.
Ebben a tutorialban végigmegyünk azon, hogyan tudod ezeket pontosan lefedni az uptimes.hu admin felületén.
Mit érdemes monitorozni egy Next.js oldalon?
Egy átlagos Next.js projekthez 3-4 monitor elég:
- Egy reprezentatív frontend oldal (általában a
/és egy dinamikus route). - Egy saját
/api/healthvégpont, ami JSON-ben jelzi a DB és kritikus függőségek állapotát. - Egy ISR oldal, ha használsz revalidate-elt tartalmat.
- SSL (automatikusan figyelve).
1. Frontend oldal ellenőrzése (a hidratáció buktatójával)
A legtöbb Next.js oldal kezdő HTML-je tartalmazza a <title>-t és a fő szerver-render tartalmat. Erre lehet keyword check-et építeni, ami a tényleges tartalmat ellenőrzi, nem csak a 200-as választ.
Új monitor, HTTP(S):
| Mező | Érték |
|---|---|
| Monitor name | Next.js főoldal |
| URL | https://az-appod.hu/ |
| HTTP method | GET |
| Expected status codes | 200, 301, 302 |
| Follow redirects | be |
| Timeout | 15 mp |
| Response keyword | <title>Az oldalad címe |
Vigyázz a hidratáció csapdájával: ha az oldalad client-only komponensekből áll (pl. 'use client' minden szinten, next/dynamic ssr false-szal), akkor a szerver-renderelt HTML üres lehet, és csak a kliens böngészőjében töltődik be a tartalom. Ilyenkor a <title> vagy a meta description a legbiztosabb keyword target, mert ezt a Next.js metadata API szerver oldalon írja be.
Rossz választás keyword-nak: olyan szöveg, ami useEffect-ben vagy useState-ben dől el. Az uptimes ellenőrző nem futtat JavaScript-et, csak a szerver válaszát nézi.
2. API route monitor saját /api/health végponttal
Hozz létre egy egészségellenőrző végpontot a pages/api/health.ts vagy app/api/health/route.ts fájlban.
App Router (Next.js 13+):
// app/api/health/route.ts
import { NextResponse } from 'next/server';
import { prisma } from '@/lib/prisma'; // vagy a saját DB klienseed
export const dynamic = 'force-dynamic';
export const runtime = 'nodejs'; // db-hez ne edge legyen
export async function GET() {
const checks: Record<string, 'up' | 'down'> = {
db: 'down',
};
try {
await prisma.$queryRaw`SELECT 1`;
checks.db = 'up';
} catch {}
const allOk = Object.values(checks).every((v) => v === 'up');
return NextResponse.json(
{
status: allOk ? 'ok' : 'error',
...checks,
time: new Date().toISOString(),
},
{ status: allOk ? 200 : 503 }
);
}
Pages Router:
// pages/api/health.ts
import type { NextApiRequest, NextApiResponse } from 'next';
import { prisma } from '@/lib/prisma';
export default async function handler(req: NextApiRequest, res: NextApiResponse) {
let dbOk = false;
try {
await prisma.$queryRaw`SELECT 1`;
dbOk = true;
} catch {}
const ok = dbOk;
res.status(ok ? 200 : 503).json({
status: ok ? 'ok' : 'error',
db: dbOk ? 'up' : 'down',
time: new Date().toISOString(),
});
}
Monitor:
| Mező | Érték |
|---|---|
| Monitor name | Next.js API health |
| URL | https://az-appod.hu/api/health |
| HTTP method | GET |
| Expected status codes | 200 |
| Response keyword | "status":"ok" |
Starter csomagtól JSON field check-kel pontosabban: status = ok, db = up.
Edge runtime vagy Node runtime?
Ha a /api/health végponton DB hívás van (Prisma, raw SQL, Postgres), akkor maradj Node runtime-on. Az Edge runtime-on nem fut a legtöbb DB driver, vagy ha igen, akkor connection pooling-gel kell foglalkozni. Az egészségellenőrző végpont nem teljesítmény-kritikus, a Node runtime megbízhatóbb.
3. ISR oldal ellenőrzése
Ha használsz revalidate-elt oldalakat (export const revalidate = 60 vagy getStaticProps revalidate-tel), akkor érdemes legalább egyet monitorozni. Az ISR azért problémás, mert ha a háttér revalidate hibára fut, a látogató egy stale oldalt kap, és a 200-as válasz miatt minden monitor UP-ot mutat.
A megoldás: az ISR oldalon szerepeljen egy szerver oldalon renderelt timestamp vagy verzió jelző. Pl. a <head> szekcióban:
export default async function Page() {
const lastBuild = process.env.VERCEL_GIT_COMMIT_SHA?.slice(0, 7) ?? 'dev';
return (
<>
<meta name="build-id" content={lastBuild} />
{/* ... */}
</>
);
}
Önmagában a build-id nem mondja meg, hogy az ISR friss-e, de ha kombinálod egy lekért adatpontnak az ISO timestamp-jével (pl. utolsó cikk publikálási dátuma), akkor a keyword check meg tudja fogni a stale-t.
Egyszerűbb megközelítés: az ISR oldalon szerepeljen valami szövegrészlet, ami akkor változik, amikor az adat frissül. Pl. legutóbbi bejegyzés címe. Ha a keyword pointja "Most legfrissebb cím", és az adat hetekig nem változik, akkor látszik, hogy az ISR megakadt.
SSL és deploy ellenőrzés
Az SSL tanúsítvány lejáratot minden HTTPS monitor mellett automatikusan figyeljük (30, 14, 7 és 1 nappal lejárat előtt). Vercel és Netlify automatikus Let's Encrypt megújítást használ, de néha eltörik (pl. domain DNS változás után).
Deploy monitor: ha Vercel-en vagy Netlify-on hostolsz, akkor a deploy webhook-okat is be tudod kötni az uptimes.hu felé. Ehhez azonban a Vercel project webhook endpoint-jára kell egy ingoming webhook URL, ami nem minden csomagban érhető el.
Vercel és önhostolt környezetek különbsége
| Szempont | Vercel | Önhostolt (Node + Nginx) |
|---|---|---|
| Cold start latency | jelentős lehet függvényeknél | nincs |
/api/health runtime |
force Node, ne edge | nincs különbség |
| SSL | automatikus | saját Let's Encrypt vagy Cloudflare |
| Deploy preview URL-ek | sok mini-monitor | egy main URL |
| Middleware hiba | minden kérés 500 | minden kérés 500 |
Vercel-en a /api/health első hívása lehet 1-2 másodperc cold start miatt. Ha 10 mp timeout-ot adsz és csak percenként hívod, akkor a cold start nem okoz false-DOWN-ot, mert addigra felépült a function.
Ajánlott monitor portfólió Next.js alkalmazáshoz
| # | Monitor | URL | Interval | Check |
|---|---|---|---|---|
| 1 | Főoldal | https://az-appod.hu/ |
1 perc | keyword: <title>... |
| 2 | API health | https://az-appod.hu/api/health |
1 perc | JSON: status=ok, db=up |
| 3 | Dinamikus oldal | https://az-appod.hu/blog/legutobbi-cikk-slug |
5 perc | keyword: a cikk címe |
| 4 | Bejelentkező flow | https://az-appod.hu/auth/sign-in |
5 perc | keyword: name="email" |
A 3. monitort akkor érdemes felvenni, ha SSG/ISR-rel renderelt blogot vagy katalógust üzemeltetsz. Egy stabilan publikált cikk URL-jét add meg, és a keyword check a cikk címét nézze.
Próbáld ki ingyen
Az ingyenes csomaggal 5 monitort tudsz futtatni 5 perces intervallumon. SSL figyelés, email értesítés alapból. Pont elég egy Next.js project teljes lefedéséhez.
Ha JSON field check-et használnál a /api/health végponton, akkor a Starter csomag tudja, percenkénti gyakorisággal.
Regisztrálj ingyen, és állítsd be az első Next.js monitort 5 perc alatt. Bankkártya nem kell az induláshoz.