Zenith Reborn

Adding Professional Error Monitoring to Zenith Reborn

How we integrated Sentry for real-time error tracking, session replays, and production monitoring in under 2 hours.

#feature#devops#performance
Adding Professional Error Monitoring to Zenith Reborn

Why Error Monitoring Matters

When you're running a production website, errors are inevitable. The question isn't if they'll happen—it's whether you'll know about them when they do.

Before implementing Sentry, we had no visibility into production errors. Users might encounter issues, and we'd never know unless they reported them manually. That's not acceptable for a professional web presence.

The Solution: Sentry Integration

We chose Sentry as our error monitoring platform for several compelling reasons:

  • Real-time notifications - Get alerted the moment errors occur
  • Session replays - Watch video-like replays of user sessions leading to errors
  • Stack traces - See exactly where and why errors happened
  • Free tier - 5,000 errors/month is more than enough for most sites
  • Easy integration - Official Next.js SDK with zero-config setup

What We Built

Complete Error Coverage

We implemented Sentry across all runtime environments:

Client-side monitoring (sentry.client.config.ts):

import * as Sentry from "@sentry/nextjs";

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  tracesSampleRate: 1.0,
  replaysOnErrorSampleRate: 1.0,
  replaysSessionSampleRate: 0.1, // 10% sampling
  integrations: [
    Sentry.replayIntegration({
      maskAllText: true,
      blockAllMedia: true,
    }),
  ],
});

Server-side monitoring (sentry.server.config.ts and sentry.edge.config.ts):

  • Captures API route errors
  • Monitors server-side rendering failures
  • Tracks edge runtime issues

Global error hooks (instrumentation.ts):

export async function onRequestError(err: unknown, request, context) {
  Sentry.captureException(err, {
    contexts: {
      nextjs: {
        request: { path: request.path, method: request.method },
        router: context.routerKind,
        route: context.routePath,
        type: context.routeType,
      },
    },
  });
}

This hook automatically captures errors from nested React server components—a common blind spot in Next.js applications.

Error Boundaries

We created two levels of error protection:

Page-level error boundary (app/error.tsx):

"use client";

import * as Sentry from "@sentry/nextjs";

export default function Error({ error, reset }: ErrorProps) {
  useEffect(() => {
    // Capture error in Sentry
    Sentry.captureException(error);
  }, [error]);

  return (
    <div className="error-page">
      {/* Phoenix-themed error UI */}
    </div>
  );
}

Root error boundary (app/global-error.tsx):

  • Catches critical errors in the root layout
  • Last line of defense before complete app failure
  • Phoenix-themed design matching our brand

Production Testing

We didn't just deploy and hope—we thoroughly tested the integration:

  1. Created test endpoints to trigger errors on demand
  2. Deployed to production at zenithreborn.com
  3. Triggered both client and server errors using automated tests
  4. Verified in Sentry dashboard that errors appeared with full context

All tests passed. ✅

Technical Details

Dependency Updates

Alongside Sentry, we updated core dependencies:

  • Tailwind CSS: 4.1.14 → 4.1.16 (patch fixes)
  • @types/node: 24.8.1 → 24.9.1 (latest type definitions)

Bundle Size Impact

Adding Sentry increased our shared JavaScript bundle:

  • Before: 102 kB shared chunk
  • After: 213 kB shared chunk (+111 kB)
  • Total homepage: 229 kB (still 71 kB under our 300 kB target)

The trade-off is worth it—professional error monitoring is essential for production applications.

Configuration

The setup required three environment variables:

NEXT_PUBLIC_SENTRY_DSN=https://xxxxx@xxxxx.ingest.sentry.io/xxxxx
SENTRY_ORG=your-org-name
SENTRY_PROJECT=zenith-reborn-website

We documented the complete setup process in SENTRY_SETUP.md for future reference.

What We Learned

1. Always Test in Production

Local testing is essential, but production testing revealed nuances we missed:

  • Different error context (prod vs dev environments)
  • Source map upload verification
  • Actual notification delivery
  • Session replay capture rates

2. Error Boundaries are Critical

Next.js doesn't provide default error boundaries. Without them, errors crash the entire app. Our custom boundaries:

  • Provide graceful degradation
  • Show users helpful recovery options
  • Maintain brand consistency (phoenix theme)
  • Capture errors for debugging

3. Privacy Matters

Sentry's session replay feature is powerful but requires careful configuration:

maskAllText: true,      // Hide all text content
blockAllMedia: true,    // Block images/videos

This ensures we capture user actions without compromising privacy—a crucial balance for GDPR compliance.

Results

After deploying to production:

Real-time error notifications via email ✅ Full stack traces with source maps ✅ Session replays for 10% of error occurrences ✅ Production-ready monitoring with zero ongoing maintenance

The entire implementation took about 2 hours, including:

  • Initial setup and configuration
  • Creating test endpoints
  • Production deployment and testing
  • Documentation

What This Means for Zenith Reborn

We now have professional-grade error monitoring that rivals enterprise applications:

  • Proactive issue detection - Know about problems before users report them
  • Faster debugging - Session replays show exactly what happened
  • Better user experience - Fix issues quickly with detailed context
  • Peace of mind - Confident that critical errors won't go unnoticed

Next Steps

With error monitoring in place, we can:

  1. Track error trends over time
  2. Set up custom alerts for critical issues
  3. Monitor performance (Sentry supports transaction tracking)
  4. Release tracking (see which deployments introduce errors)

Want to add Sentry to your Next.js project? The official @sentry/nextjs SDK makes it incredibly easy. Our SENTRY_SETUP.md guide walks through the entire process step-by-step.

The investment in proper error monitoring pays dividends from day one. When that first production error occurs (and it will), you'll be glad you can see exactly what happened and fix it quickly.


Built with Next.js 15, React 19, and @sentry/nextjs. Tested on zenithreborn.com.

Geschreven door Hans

Comments

Sign in with GitHub to leave a comment. Comments are powered by Giscus.