Next.js 15 Error Handling: error.tsx, Server Actions, and Sentry (2026)

Navigating the Storm: Next.js 15 Error Handling, Server Actions, and Sentry in 2026

I've been building web applications for a while now, and one truth remains constant: errors happen. They always do. I still recall the panicked call from a client, "The entire checkout page is blank!" My stomach dropped. Turns out, a seemingly innocuous API call in a deeply nested component had failed, and without proper error boundaries, the whole thing just silently imploded. We were logging some errors, sure, but understanding the context and gracefully recovering the UI? That was a scramble.

This experience taught me a profound lesson: error handling isn't just about preventing crashes; it's about delivering a resilient, understandable user experience and giving your team the tools to diagnose issues quickly. And as we push deeper into the capabilities of frameworks like Next.js 15, especially with its powerful Server Actions and the declarative error.tsx boundaries, our approach to error handling needs to evolve. We're building full-stack applications with an unprecedented level of integration between client and server, meaning errors can originate anywhere and propagate in fascinating, sometimes frustrating, ways.

The Declarative Embrace: error.tsx in Next.js 15

Gone are the days where you'd manually sprinkle try/catch blocks around every potential client-side failure point just to show a fallback UI. Next.js 15's error.tsx is a game-changer, embracing a declarative pattern akin to React's Error Boundaries but deeply integrated into the App Router.

Here's the thing: error.tsx acts as an error boundary for a segment of your application. If an error is thrown within that segment (or any of its children), error.tsx catches it, prevents the crash, and allows you to display a fallback UI, keeping the rest of your application functional. This means instead of your entire page going blank, perhaps just a single widget or a specific data display fails gracefully.

// app/dashboard/error.tsx
'use client'; // Error boundaries must be client components

import { useEffect } from 'react';

export default function Error({
  error,
  reset,
}: {
  error: Error & { digest?: string };
  reset: () => void;
}) {
  useEffect(() => {
    // Optionally log the error to an error reporting service
    // In my experience, this is critical for server-side errors that bubble up
    console.error(error);
  }, [error]);

  return (
    <div className="flex flex-col items-center justify-center p-8 bg-red-100 border border-red-400 rounded-lg">
      <h2 className="text-xl font-semibold text-red-800">Something went wrong!</h2>
      <p className="mt-2 text-red-700">We're sorry, but there was an issue loading this section.</p>
      <button
        className="mt-4 px-4 py-2 bg-red-600 text-white rounded hover:bg-red-700 transition-colors"
        onClick={
          // Attempt to recover by trying to re-render the segment
          () => reset()
        }
      >
        Try again
      </button>
      <p className="mt-2 text-sm text-red-500">Error digest: {error.digest || 'N/A'}</p>
    </div>
  );
}

Notice the 'use client' directive. If your error.tsx needs interactivity (like that "Try again" button), it must be a client component. What I've found incredibly powerful is how this system prevents cascading failures. If your error.tsx is at app/dashboard/error.tsx, an error in app/dashboard/settings/page.tsx will be caught by that boundary, not taking down the entire dashboard layout.

Taming the Backend Beast: Errors in Server Actions

Server Actions are incredible for unifying client-side interactions with server-side logic, but they introduce a new dimension to error handling. When an error occurs within a Server Action, it doesn't automatically trigger the nearest error.tsx on the client. Why? Because the Server Action executes on the server, and its result (or error) is returned to the client-side code that invoked it.

This means you absolutely must wrap your Server Action logic in try/catch blocks if you want to handle specific error conditions gracefully or return user-friendly messages.

// app/dashboard/actions.ts
'use server';

import { revalidatePath } from 'next/cache';

export async function createProduct(formData: FormData) {
  try {
    const name = formData.get('name') as string;
    const price = parseFloat(formData.get('price') as string);

    if (!name || isNaN(price) || price <= 0) {
      throw new Error('Invalid product data provided.');
    }

    // Simulate a database operation that might fail
    const result = await fetch('https://api.example.com/products', {
      method: 'POST',
      body: JSON.stringify({ name, price }),
      headers: { 'Content-Type': 'application/json' },
    });

    if (!result.ok) {
      // Here, we catch API errors and re-throw a more controlled error
      const errorData = await result.json();
      throw new Error(errorData.message || 'Failed to create product.');
    }

    revalidatePath('/dashboard/products');
    return { success: true, message: `Product "${name}" created!` };
  } catch (error: any) {
    // Log the error for server-side debugging BEFORE returning to client
    console.error('Server Action Error: ', error);
    // Return a structured error object to the client
    return { success: false, message: error.message || 'An unexpected error occurred.' };
  }
}

On the client side, you then handle this returned error:

// app/dashboard/page.tsx
'use client';

import { useState } from 'react';
import { createProduct } from './actions';

export default function DashboardPage() {
  const [statusMessage, setStatusMessage] = useState<string | null>(null);
  const [isSubmitting, setIsSubmitting] = useState(false);

  const handleSubmit = async (event: React.FormEvent<HTMLFormElement>) => {
    event.preventDefault();
    setIsSubmitting(true);
    setStatusMessage(null);

    const formData = new FormData(event.currentTarget);
    const result = await createProduct(formData); // Call the server action

    if (result.success) {
      setStatusMessage(`Success: ${result.message}`);
    } else {
      setStatusMessage(`Error: ${result.message}`);
    }
    setIsSubmitting(false);
  };

  return (
    <div className="p-8">
      <h1 className="text-2xl font-bold mb-4">Create New Product</h1>
      <form onSubmit={handleSubmit} className="space-y-4">
        <div>
          <label htmlFor="name" className="block text-sm font-medium text-gray-700">Product Name</label>
          <input type="text" id="name" name="name" className="mt-1 block w-full border border-gray-300 rounded-md shadow-sm p-2" required />
        </div>
        <div>
          <label htmlFor="price" className="block text-sm font-medium text-gray-700">Price</label>
          <input type="number" id="price" name="price" step="0.01" className="mt-1 block w-full border border-gray-300 rounded-md shadow-sm p-2" required />
        </div>
        <button type="submit" disabled={isSubmitting} className="px-4 py-2 bg-blue-600 text-white rounded-md hover:bg-blue-700 disabled:opacity-50">
          {isSubmitting ? 'Creating...' : 'Create Product'}
        </button>
      </form>
      {statusMessage && (
        <p className={`mt-4 ${statusMessage.startsWith('Error') ? 'text-red-600' : 'text-green-600'}`}>
          {statusMessage}
        </p>
      )}
      {/* This component could also throw an error from other logic, which error.tsx would catch */}
      {/* Example: <ProductList /> which might fail to fetch initial data */}
    </div>
  );
}

The critical insight here is that error.tsx only catches errors that occur during the render cycle or data fetching within its boundary. Errors from Server Actions that are properly try/catch-ed and return a structured result object will be handled imperatively by your client component. However, if a Server Action throws an uncaught error on the server and that error then causes a rendering issue (e.g., corrupt data invalidates a React component's expectations), then error.tsx might catch the subsequent client-side rendering error. It's a nuanced distinction, but vital for robust design.

The Watchful Eye: Sentry for Comprehensive Observability

error.tsx provides a beautiful user experience. Your try/catch in Server Actions gives you granular control. But neither tells you what truly happened across your entire application, in production, when you're not actively debugging. This is where Sentry (or a similar error monitoring tool) becomes indispensable.

In my experience, if you're not capturing errors consistently across both your client and server, you're flying blind. Next.js 15, with its client/server component architecture, requires a dual-pronged Sentry setup:

1. Client-side Sentry: Captures errors that bubble up from your client components, typically caught by error.tsx (which then logs it) or unhandled errors in your interactive client-side logic.
2. Server-side Sentry: Critical for capturing errors within your Server Components, Server Actions, API routes, and any other Node.js logic. These are errors that often happen before a browser even sees anything.

The setup usually involves initializing Sentry in sentry.client.config.ts and sentry.server.config.ts, ensuring you have the correct DSNs and environment variables. Then, within your error.tsx component, you'd use Sentry.captureException(error) in the useEffect hook. For Server Actions, you'd integrate Sentry.captureException(error) directly within your catch block before returning the error to the client.

// app/sentry.server.config.ts (simplified example)
import * as Sentry from "@sentry/nextjs";

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  // ... other configs
});

// app/dashboard/actions.ts (updated for Sentry)
'use server';

import { revalidatePath } from 'next/cache';
import * as Sentry from "@sentry/nextjs"; // Import Sentry

export async function createProduct(formData: FormData) {
  try {
    // ... existing logic ...
  } catch (error: any) {
    console.error('Server Action Error: ', error);
    Sentry.captureException(error); // Capture this server-side error
    return { success: false, message: error.message || 'An unexpected error occurred.' };
  }
}

This holistic approach gives you stack traces, user context, breadcrumbs, and release monitoring, helping you move from "what happened?" to "what caused it, who was affected, and how do we fix it?"

Pitfalls to Avoid (Lessons Learned the Hard Way)

• Forgetting use client in error.tsx: If your error.tsx needs state, event handlers, or effects, it must be a client component. I've wasted precious minutes debugging hydration errors because of this oversight.
• Not logging server-side errors: An error caught by error.tsx on the client might have originated on the server. If you don't log it on the server (e.g., in your Server Action's catch block or a global server-side error handler), you'll miss crucial context. Sentry helps bridge this gap.
• Over-catching vs. letting error.tsx handle it: Distinguish between operational errors (like "invalid input") that you handle gracefully within your logic, and unexpected programming errors (like a TypeError from missing data) that error.tsx should catch. Don't try/catch everything; let the boundaries do their job for true exceptions.
• Incomplete Sentry setup: Ensure both client-side and server-side Sentry configurations are correct. It's easy to miss one, leading to blind spots. Test your error logging in development and staging environments.
• Testing error boundaries: Actively test your error.tsx components. Intentionally throw errors in different parts of your app to ensure the correct boundary catches them and displays the expected fallback.

Wrapping It Up: Building Resilient Next.js Apps

Next.js 15, with its advanced error handling mechanisms and the power of Server Actions, empowers us to build incredibly dynamic and efficient applications. But with great power comes the need for robust error strategies.

By thoughtfully employing error.tsx for graceful UI degradation, strategically using try/catch within your Server Actions for granular control, and integrating a comprehensive observability platform like Sentry, you’re not just catching errors; you're building a resilient, maintainable, and ultimately more user-friendly application. Embrace these tools, and you’ll find yourself spending less time reacting to production fires and more time innovating.

---

✨ Let's keep the conversation going!

If you found this interesting, I'd love for you to check out more of my work or just drop in to say hello.

✍️ Read more on my blog: bishoy-bishai.github.io

☕ Let's chat on LinkedIn: linkedin.com/in/bishoybishai

---