Stop Flying Blind: Error Handling & Logging Best Practices for Production Apps

“

Meerako — We build 5.0★, reliable applications with enterprise-grade error handling and observability.

Production errors are inevitable — a third-party API goes down, a user submits unexpected input, a database connection drops momentarily. What actually separates a professional, reliable application from an amateur one isn't the absence of errors; it's how they're handled and logged so your team catches and fixes them before users notice, or at minimum before users have to file a complaint about it.

A stray console.log('Error!') followed by an app crash isn't a strategy. Robust error handling and structured logging are core to every application we build, tied directly into our broader observability approach. Here's how we approach it in practice, with Node.js specifically.

• Why unhandled exceptions are a genuine reliability failure, not an acceptable edge case.
• The meaningful distinction between operational errors and programmer errors.
• Why structured logging matters once you're past a handful of requests per day.
• How proactive error tracking replaces waiting for user complaints as your bug-discovery mechanism.

In Node.js, an uncaught exception or unhandled promise rejection can crash the entire server process — a serious, avoidable failure mode. The fix is global error handlers at the application's top level:

// In your main server.js (simplified example)

process.on('uncaughtException', (error) => {
  console.error('UNCAUGHT EXCEPTION! Shutting down...', error);
  // Log the error to your tracking service before exiting
  process.exit(1);
});

process.on('unhandledRejection', (reason, promise) => {
  console.error('UNHANDLED REJECTION! Shutting down...', reason);
  process.exit(1);
});

const app = require('./app');

The key discipline: log the error thoroughly, then shut down gracefully rather than attempting to "recover" from an unknown, potentially corrupted state. A process manager (PM2, or Kubernetes at the orchestration layer) handles the automatic restart.

Not every error deserves the same response. Operational errors are expected, anticipatable failures — invalid user input, a third-party API timeout, a lost database connection. Code should handle these gracefully: log them, potentially retry, and return a specific, appropriate error to the user (a 400 Bad Request, for instance). Programmer errors — genuine bugs, like a TypeError from an unexpected undefined value — represent a real flaw in the code and shouldn't be silently retried or masked. These should trigger the global handlers above, log a full stack trace, and restart the process rather than continue running in a state the code clearly didn't anticipate.

console.log('User logged in') becomes genuinely useless once you're handling meaningful request volume — plain text logs are hard to search, filter, or analyze systematically. A dedicated logging library (Pino or Winston for Node.js) outputs structured JSON instead:

{
  "level": "info",
  "time": 1678886400000,
  "message": "User login successful",
  "userId": 123,
  "sourceIp": "192.168.1.100"
}

Shipped to a centralized logging platform — CloudWatch Logs, Loki, Elasticsearch — this structure makes precise queries possible ("show every error-level log for userId 123") and enables dashboards built directly from log data, neither of which plain-text logs support well.

Waiting for users to report bugs is purely reactive. Integrating an error tracking service — Sentry, Bugsnag, Datadog APM — makes discovery proactive instead: the SDK automatically captures unhandled exceptions with full stack trace and request context (headers, user ID) and alerts your team immediately, often directly in Slack, with everything needed to start debugging. We integrate Sentry into every application we build as a standard, not an optional add-on.

Never expose a raw stack trace or a cryptic database error message to an end user. Operational errors deserve clear, actionable messaging ("invalid email format — please try again"). Programmer errors (500s) deserve a generic, reassuring message ("something went wrong on our end — please try again or contact support"), with the detailed technical error logged internally where the team can actually act on it.

Robust error handling and structured logging aren't optional polish — they're foundational to building professional, reliable software. They're the difference between genuinely flying blind in production and having the concrete visibility needed to diagnose and fix problems quickly, often before a single user notices something went wrong.

Ready to build your application with enterprise-grade reliability baked in?