Tutorial Monitoring

Next.js alkalmazás monitorozása: mit és hogyan figyelj

Hogyan figyeld egy Next.js app működését? Frontend hidratáció, API route-ok, ISR oldalak és Vercel deploy uptime ellenőrzés lépésről lépésre.

2026. május 17. 7 perces olvasás Frissítve: 2026. június 3.

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 revalidate hibá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:

  1. Egy reprezentatív frontend oldal (általában a / és egy dinamikus route).
  2. Egy saját /api/health végpont, ami JSON-ben jelzi a DB és kritikus függőségek állapotát.
  3. Egy ISR oldal, ha használsz revalidate-elt tartalmat.
  4. 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.

Próbáld ki az uptimes.hu-t ingyen

Ingyenes csomag, nincs bankkártya, percek alatt elindul.