How to catch and handle errors to report logs on server side

[acanimal]

Hi,
I'm in the situation where we want to sent errors, both on server and client side, to Sentry tool.

Our app uses Express as a custom server. Basically we create an express app, apply some middlewares but delegate all the real job to the next.js handle:

  const app = nextJs({ dev: process.env.NODE_ENV !== 'production' });
  const handler = routes.getRequestHandler(app);
  const expressApp = express();

  ...
  ...

  expressApp.use(morgan('combined', { stream: logger.stream }));
  expressApp.use(statsdMiddleware);

  // Add security
  expressApp.use(helmet());

  // Sentry handler
  expressApp.use(sentry.requestHandler());

  // Load locale and translation messages
  expressApp.use(i18n);

  // Next.js handler
  expressApp.use(handler);

  // Sentry error handler.
  // MUST be placed before any other express error handler !!!
  expressApp.use(sentry.errorHandler());

With this approach next.js takes control over the rendering process and any error is catch by next.js and the only way I have to process it is overriding the _error.js page file.

Within that _error.js file I need a universal way to report errors to Sentry. Currently there are two libraries (raven for node and raven-js por javascript). The proble is I can't import both of them because raven works for SSR but fails when webpack builds the bundle, and also raven-js fails due XMLHTTPRequest dependency too.

Is there a way I can be notified for next.js error on server side?

[jgautheron]

For logging errors in the client side we have been doing the following:
https://gist.github.com/jgautheron/044b88307d934d486f59ae87c5a5a5a0

It basically sends errors to the server, that are in the end printed to stdout and caught by our Docker logging driver.
We have successfully caught SSR errors with react-guard with no need to override core Next files.

[ethanresnick]

I'm also having this problem. I wonder: would simply returning a rejected promise from next's handleRequest be sufficient? That is, changing the code here to be:

handleRequest (req, res, parsedUrl) {
  // .....snip....

   return this.run(req, res, parsedUrl)
     .catch((err) => {
       if (!this.quiet) console.error(err)
       res.statusCode = 500
       res.end(STATUS_CODES[500])
 
       // rethrow error to create new, rejected promise 
       throw err;
     })
}

Then, in user code:

const app = nextJs({ dev: process.env.NODE_ENV !== 'production' });
const nextJsHandler = app.getRequestHandler();
const expressApp = express();

app.prepare().then(() => {
   // invoke express middlewares
   // ...

   // time to run next
   expressApp.use(function(req, res, next) {
     nextJsHandler(req, res).catch(e => {
       // use rejected promise to forward error to next express middleware
       next(e)
     })
   });

   // Use standard express error middlewares to handle the error from next
   // this makes it easy to log to sentry etc.
})

[ethanresnick]

@arunoda @rauchg Do you think the change I proposed immediately above would work? If so, happy to submit a PR

[hunt]

Agree to re-throw an error so we can play around with it.
Also need to re-throw at renderToHTML too...

[coox]

I am also in the situation where we want to sent errors, both on server and client side, to a service similar to Sentry.

I believe that the most valuable feature of such services/tools is to report issues that are most unexpected, which in my experience are uncaught errors in the wild (ie. client-side). Unfortunately, as previously stressed out in related issue #2334, Next.js’ client-side handlers keep these errors to themselves, with no possible way to pass them to Sentry of such other tool.

What has bitten us particularly hard is this: a properly server-side rendered page is re-rendered as an error page if an uncaught exception occurs before React rendering on the client-side. This can be seen as either a great feature, but also a frustrating developer experience, as it essentially ruins the benefits of serving an already rendered document, on a surprisingly portion of clients.

Here is a sample page that illustrates the problem:

import React from 'react';

// Works well in Node 8, but crashes in Chrome<56, Firefox<48, Edge<15, Safari<10, any IE…
const whoops = 'Phew, I made it to the client-side…'.padEnd(80);

export default () => <pre>{whoops}</pre>;

The above code can be perfectly server-side-rendered and delivered to the client, only to become a Flash Of Unwanted Content before the whole page is replaced on the client-side by the dreaded ”An unexpected error has occurred” message on most browsers, without any possible way to report the error to Sentry (or any other service/tool).

This ”error swallowing” also prevents any leverage of the standard onerror handler, which most client-side error reporting tools hook onto (or the more modern, but not widespread, onunhandledrejection, which may be more suitable given the async nature of client-side code).

Possible client-side solution

As far as I can tell, this type of pre-React client-side error is swallowed in the try/catch block in Next.js’ client/index.js where the Component about to be rendered is re-assigned to the value of ErrorComponent (currently lines 67-72).

Dear Next.js authors and maintainers, for the sake of control of what is rendered, what would you think would be acceptable/possible among the following ideas:

• introduce a hook in that catch block in client/index.js for handling this kind of error?
• transmit the error to an onerror/onunhandledrejection handler, if any is detected?
• provide an option to rethrow the error?
• provide an option to not display the error component?
• provide an option to display a custom error component?

[timneutkens]

introduce a hook in that catch block in client/index.js for handling this kind of error?
transmit the error to an onerror/onunhandledrejection handler, if any is detected?

This is something we've talked about internally. And we'll be addressing soon.

[Shelco]

Hi,
just curious, are you still considering adding this type of hook in a coming release or is there another way of accomplishing this in 2022 besides using a custom server or monkey patching console log?
Thanks

[c0b41]

@timneutkens year 2024 and still no support for loggin?

[acanimal]

I'm using Sentry.io to report errors and the solution we apply is:

1- Configure raven-node on server side
2- Configure ravenjs on client side (we made that on _document.

With this two steps we catch any unhandled exceptions both on client and server.

3- Create an _error page. Any error produced once nextjs handles the request (no matter if client or server side) that page is rendered. In the getInitialProps method of the _error page we report the error to sentry.

The way to decide how to load if raven-node or ravenjs is solved importing dynamically depending if we are in client const Raven = require('raven-js'); or server side const Raven = require('raven');.
Note we have configured webpack to not bundle the raven module (the server side one) updating next.config.js with:

const webpack = require('webpack');

module.exports = {
  // Do not show the X-Powered-By header in the responses
  poweredByHeader: false,
  webpack: (config) => {
    config.plugins.push(new webpack.IgnorePlugin(/^raven$/));
    return config;
  },
};

[tusgavomelo]

@acanimal

2- Configure ravenjs on client side (we made that on _document.

Can you show me how did you configured raven-js on your _document.js? It's not working for me, when any error occur nothing happens on sentry.

Do I need to send the all the errors manually at _error.js page to sentry?

// _document constructor
constructor(props) {
    super(props);
    Raven
      .config('...')
      .install();
}

[damusnet]

Next.js still outputs errors to console.error on the server as long as you don't set it to quiet.

With Sentry, you can enable autoBreadcrumbs to capture this output, and then capture your own message manually. The title will be less descriptive, but it will still contain the full stack trace.

Example implementation:

const express = require('express');
const nextjs = require('next');
const Raven = require('raven');

const dev = process.env.NODE_ENV !== 'production';

// Must configure Raven before doing anything else with it
if (!dev) {
  Raven.config('__DSN__', {
    autoBreadcrumbs: true,
    captureUnhandledRejections: true,
  }).install();
}

const app = nextjs({ dev });
const handle = app.getRequestHandler();

const captureMessage = (req, res) => () => {
  if (res.statusCode > 200) {
    Raven.captureMessage(`Next.js Server Side Error: ${res.statusCode}`, {
      req,
      res,
    });
  }
};

app
  .prepare()
  .then(() => {
    const server = express();

    if (!dev) {
      server.use((req, res, next) => {
        res.on('close', captureMessage(req, res));
        res.on('finish', captureMessage(req, res));
        next();
      });
    }

    [...]

    server.get('/', (req, res) => {
      return app.render(req, res, '/home', req.query)
    })

    server.get('*', (req, res) => {
      return handle(req, res)
    })

    server.listen('3000', (err) => {
      if (err) throw err
      console.log(`> Ready on http://localhost:${port}`)
    })
  })
  .catch(ex => {
    console.error(ex.stack);
    process.exit(1);
  });

This is a very contrived example adapted from our actual code. I haven't tested it in this form. Let me know if it breaks.

Of course, it would still be best if Next.js could pass those errors around to Express, so that we can use the Sentry/Express integration out of the box.

[acanimal]

@tusgavomelo Sorry, for the late reply.

We have update. In our app we have a helper file with a method responsible to get a Raven instance taking into account if we are on client or server side.

let clientInstance;
let serverInstance;

const getRavenInstance = (key, config) => {
  const clientSide = typeof window !== 'undefined';

  if (clientSide) {
    if (!clientInstance) {
      const Raven = require('raven-js');  // eslint-disable-line global-require
      Raven.config(key, config).install();
      clientInstance = Raven;
    }

    return clientInstance;
  }

  if (!serverInstance) {
    // NOTE: raven (for node) is not bundled by webpack (see rules in next.config.js).
    const RavenNode = require('raven'); // eslint-disable-line global-require
    RavenNode.config(key, config).install();
    serverInstance = RavenNode;
  }
  return serverInstance;
};

This code runs both server side (when a request arrives) and client side. What we have done is configure webpack (next.config.js file) to avoid bundle the raven package.

[Fettah]

@acanimal can you maybe provide a working example ? It seems I am not getting the full stack trace ? or maybe can you post your _error.js?

I am doing something like RavenInstance.captureException(err) in my _error.js, but I do not get to see the type of errors that occured as well as where?

export default class Error extends React.Component {
  static getInitialProps({ res, err }) {
    const RavenInstance = getRavenInstance('__SENTRY__')
    if (!(err instanceof Error)) {
      err = new Error(err && err.message)
    }
    RavenInstance.captureException(err)
    // const statusCode = res ? res.statusCode : err ? err.statusCode : null;

    return { }
  }

  render() {
    return (
      <div>
        <p>An error occurred on server</p>
      </div>
    )
  }
}

[wenzowski]

This seems like the place to ask for custom logger support since quiet must be set to false to prevent next clearing screen on module rebuild and thus purging errors from view, yet the only workable hack here requires setting quiet to false.

[tusgavomelo]

The errors details are also available on the stderr stream.
process.stderr.write = error => yourErrorLog(error);

[ghost]

Gotta love unortodox solutions

function installErrorHandler(app) {
  const _renderErrorToHTML = app.renderErrorToHTML.bind(app)
  const errorHandler = rollbar.errorHandler()

  app.renderErrorToHTML = (err, req, res, pathname, query) => {
    if (err) {
      errorHandler(err, req, res, () => {})
    }

    return _renderErrorToHTML(err, req, res, pathname, query)
  }

  return app
}
// ¯\_(ツ)_/¯

[Tarabyte]

Compact version of how to get correct Raven for node and browser w/o custom webpack config. Inspired by @acanimal comment

// package.json
"browser": {
    "raven": "raven-js"
}

// getRaven.js
const Raven = require('raven')

if (process.env.NODE_ENV === 'production') {
  Raven.config('YOUR_SENTRY_DSN').install()
}

module.exports = Raven

Gist

[justjake]

@kelly-tock okay, I wrote up a quick note about how we use preloading with NextJS: https://jake.tl/notes/2021-04-04-nextjs-preload-hack

[shem8]

Hi, 2 things that I still don't understand regarding this issue:

1. You keep mentioning middleware as a way to solve it, but from what I see in Next.js you have to call the middleware in every API call. This is not very useful. In Express you set the middleware once on the server and it called for every request.
2. There're many more monitoring tools out there, you're very focused on Sentry and give a built-in solution for integrating with this, but the platform has to give so a way for developers to customize the error handling so we'll be able to use other tools too (Rollbar in my example).

[thomasboyt]

@justjake Thanks for the excellent writeup! While having to monkey-patch logging is a shame, I think using --require for adding instrumentation/error handling is fairly "elegant" as far as these things go.

Sentry just released a new official Next.js SDK that has an interesting approach: it actually injects Sentry setup into the Webpack bundles for your app, both the client and server (https://github.com/getsentry/sentry-javascript/blob/master/packages/nextjs/src/utils/config.ts#L154-L155). Unfortunately, we're using Rollbar at my company, and Rollbar doesn't have any Next.js integration, so we'll have to do a manual setup. The --require route seems much easier, but I wonder if maybe the Webpack solution has some other advantages I'm missing (besides not having to remember to use different command line arguments).

In general, I think Next.js docs should incorporate discussion of error reporting. I had deferred adding error handling to the "last 10% work" of a new project launch and spent yesterday in a bit of a panic trying to figure out how on earth I was going to add it. I had just assumed it'd be as easy as adding Sentry/Rollbar/Bugsnag/etc usually is - just add it to the entry point - until I realized Next has no "entry point" without a custom server. If the use of --require to register such things is the "happy path" for Next apps, I think it absolutely needs to be documented, rather than be buried here in a 4 year old GitHub issue.

[Vadorequest]

@thomasboyt Thanks for pointing out Sentry released something for Next.js! I'm gonna take a look at it very soon!

For anyone interested: https://sentry.io/for/nextjs/

Also, we mentionned logging above, and we've released https://github.com/UnlyEd/simple-logger a few days ago, which is 1kB an universal. After trying out a lot of open source alternatives, we couldn't find something that felt just right. Maybe you'll find it as useful as we do!

[hems]

@kelly-tock okay, I wrote up a quick note about how we use preloading with NextJS: https://jake.tl/notes/2021-04-04-nextjs-preload-hack

thanks for writing that out but indeed we need a generic "error handler" for the server like pretty much any express.js production app will end up having so unexpected errors can be caught, a user-friendly 500 can be return and the error can be sent to any error reporting library.

fingers crossed this will be sorted out soon as it's rather important.

[meotimdihia]

@kelly-tock okay, I wrote up a quick note about how we use preloading with NextJS: https://jake.tl/notes/2021-04-04-nextjs-preload-hack

I tried with this preloading script. It printed error messages but missed request URL and stack trace. It is super hard or impossible to know where the error was happening.

Edit: I have ended up using https://github.com/getsentry/sentry-javascript/tree/master/packages/nextjs

[goforbg]

The errors details are also available on the stderr stream.
process.stderr.write = error => yourErrorLog(error);

Worked for me!

[bitworking]

We need a server side ErrorBoundary 🤗

[kristijorgji]

No we can eject the server file and use express middleware to handle all unhandled exceptions (log to our logging system)
Problem here is that forces us to create custom server file.

In best case next provides a way like it has for next.config.js to capture all unhandled exceptions and do something with them

[kristijorgji]

Hi all, any update here for example like official suggested solution ?

My 5 cents here are that a proper solution would be to eject and use custom server.ts/js then wrap with another express middleware that for every catch block logs the exception to our preferred logging system. This works good for us but breaks the developer experience as having custom server in typescript like in this example https://github.com/vercel/next.js/tree/canary/examples/custom-server-typescript because cannot debug then. Nodemon ts-node node inspector with custsom next server is not working.

So my proposal is this (I think already exist need to try it)
Solution 1. Next allows to export some function for handling all unhandled server exceptions
Solution 2. I will try to use https://nextjs.org/docs/middleware middleware if possible to specify wrap all other requests and if exception is triggered log it
Solution 3. This gives us full power and works great using custom server, but please update documentation with ways how to debug as well because is broken for debug.https://github.com/vercel/next.js/tree/canary/examples/custom-server-typescript. In solution 3 we can just wrap with custom express middleware and on every error log it somewhere

[kristijorgji]

I tried using next middlewares to capture unhandled exceptions (solution 2) but did not find any way how to do it as cannot wrap the next requests and don't know order of execution.

[devinrhode2]

I've found next-logger is able to capture all api errors and turn them into a standard pino log stream

It does this by intercepting all console.* calls. When there is an exception calling an api route (error is explicitly thrown) next.js will basically call console.error(yourThrownErrorObject). So by monkey patching console.error, I believe we capture all errors.

I'm curious what exactly the sentry SDK does!

[justjake]

Usually packages like Sentry or Datadog work the same way at runtime: they monkeypatch well-known module functions and object methods. You can sometimes see this in stack traces as a sentryWrapped() stack frame.

I’m not sure if Sentry adds something special on top of runtime monkeypatching if you’re using their NextJS webpack plugin, though.

[devinrhode2]

The next-logger setup I have does NOT take into account any client side stuff. So far, it only handles server side stuff.
_{gotta love small, isolated "user stories"}

[Besuf]

After a lot of research I found the best solution to report server side rendering errors is to use custom _error.jsx and do the report inside Error component getInitialProps like below [_error.tsx]
You can refer more on _error.js here https://nextjs.org/docs/advanced-features/custom-error-page#customizing-the-500-page

[amunim]

Any solution in 2023? The getInitialProps is evaluated at build times and I have a custom server to log errors to, and the idea of moving to a custom server just to log errors doesn't appeal to me very much either. For client-side I see I can use Error Boundaries to post my logs but what about server-side?

[ivenms]

It is strange to see no ready to use solutions available in NextJs to catch and log server side errors in production..

[stychu]

[cbratschi]

Wondering if OpenTelemetry can be used to extract all errors:

https://nextjs.org/docs/app/building-your-application/optimizing/open-telemetry

I just read through the docs and don't know yet if this data is available. Probably someone knows more. I am only interested in collecting errors and storing them in our database.

[c0b41]

only possible way currently is monkey patching console api see -> #54719 (comment)

[cbratschi]

Spans contain exception data. There is an example in this blog article:

https://borstch.com/blog/development/leveraging-opentelemetry-in-nextjs-14

So there should be a way to filter span data.

[c0b41]

I did try, and yes it's possible extract errors with open telemetry