Error reports and monitoring
🏠The everyday picture
A smoke alarm that not only beeps but phones you, says which room, and when it started. You find out even when you're away.
📘What it really is
-
Users rarely report errors; they just leave. Error reporting services such as Sentry collect errors from your server (and frontend), with the stack trace, request details, user id and how often it happens, and alert you.
-
Connect them in your error handler (Module 43): every unexpected 500 is logged and reported.
-
Health checks: your
/healthroute lets the host and monitoring tools check the API is alive. A more thorough check confirms the database is reachable too. -
Uptime monitoring (Module 7) checks from outside every few minutes and alerts you.
-
Alerts should be few and meaningful. If every small warning sends a message, people learn to ignore them all. Alert on things that need action: the site is down, error rates jump, sign-in failures spike.
-
Graceful shutdown: when the server is told to stop (during a deploy), stop accepting new requests, finish the ones in progress, close connections, then exit. Listen for the
SIGTERMsignal. -
Level 6 covers monitoring in full. The habit starts now: if something fails, you should know before your users tell you.
🖱️Try it
Create a free Sentry account (or use another error service), add its Node.js package, and report unexpected errors
from your error handler. Trigger a deliberate error and find it in the dashboard. Add graceful shutdown on SIGTERM
that closes the server and logs "Shutting down".
✅Quick check
Why use an error-reporting service if you already log errors?
Show the answer
It groups errors, shows how often they happen and who's affected, and alerts you, so problems aren't missed.
What should a server do when it receives SIGTERM during a deploy?
Show the answer
Stop taking new requests, finish current ones, close connections, and exit cleanly.