Node.js SaaS Failure Monitoring: Metrics & Email Alerts

To monitor a Node.js SaaS for failures, you set up health checks, track key metrics like error rates and response times, and configure email alerts that trigger when those metrics cross a threshold. This article explains the essential metrics to watch, how to build a simple alerting pipeline with open-source tools, and how to avoid common pitfalls.

Background: Why Node.js Monitoring Is Different

Node.js is single-threaded and event-driven. A single unhandled promise rejection or a blocking synchronous operation can stall the entire process, even if the OS still reports it as healthy. Traditional server monitoring (CPU, memory) often misses these issues because the process is alive but not serving requests. That is why application-level monitoring—tracking what your code actually does—is essential for a Node.js SaaS.

Also, SaaS applications are distributed: you have API servers, background workers, databases, and third-party services. A failure can be in any of these, and the symptom might appear in a different component. For example, a slow database query can cause your API to time out, even though your Node.js code is fine. So you need to monitor the whole stack, not just the Node process.

Key Metrics to Track

Not all metrics are equally useful. For failure detection, focus on these:

• Error rate: The percentage of requests that return 5xx or 4xx (client errors can indicate bugs, but 5xx are server failures).
• Response time: The time to complete a request, especially the 95th or 99th percentile, not just the average. A few slow requests can drag the average up, hiding that most are fast.
• Throughput: Requests per second. A sudden drop to zero might mean a crash; a sudden spike might mean a DDoS or a viral post.
• Event loop lag: The delay in the event loop. If it grows, your process is blocked and not handling requests.
• Heap memory: Memory usage. A leak will eventually cause OOM (out-of-memory) crashes.
• Unhandled rejections: In Node.js, an unhandled promise rejection can crash the process (depending on version). Track them.
• Worker/queue depth: If you use background jobs, the number of pending jobs can indicate a bottleneck.

How to Set Up Monitoring and Alerts

Here is a practical approach using open-source tools that you can self-host or use as a service:

1. Instrument your app: Use a library like prom-client (for Prometheus) or @opentelemetry/sdk-node (for OpenTelemetry) to expose metrics like request count, error count, and duration histograms.
2. Expose a metrics endpoint: Typically /metrics, which returns text in Prometheus format.
3. Scrape the metrics: Run a Prometheus server (or a service like Grafana Cloud) that pulls the endpoint every 15-30 seconds.
4. Set up alert rules: In Prometheus, define rules like rate(http_requests_total{status="5xx"}[5m]) > 0.05 to alert when 5% of requests fail over 5 minutes.
5. Configure Alertmanager: Alertmanager receives alerts from Prometheus and sends notifications to email, Slack, PagerDuty, etc.
6. Add a health check endpoint: A simple /health that checks database connectivity and returns 200 or 503. Use an external uptime monitor (like UptimeRobot) to hit it every minute.
7. Test your alerts: Simulate a failure (e.g., kill a worker) and confirm you get an email.

For email specifically, Alertmanager can use SMTP. You set the SMTP server, authentication, and the recipient list. You can also add templates to make the email readable.

Common Pitfalls and How to Avoid Them

• Alert fatigue: If you alert on every minor deviation, you will ignore real alerts. Use thresholds that indicate actual user impact, and add a small duration (e.g., 5 minutes) before firing.
• Missing context: An email that says “Error rate high” is useless. Include the service name, the current value, the threshold, and a link to the dashboard.
• Not monitoring the event loop: Node.js-specific. Use process.hrtime() or a library to measure event loop delay.
• Only monitoring HTTP: If you have WebSockets or background jobs, those can fail without affecting HTTP endpoints.
• Ignoring dependencies: If your database goes down, your app might still return 200 on a health check that doesn’t check the DB. Make your health check actually test dependencies.
• No on-call rotation: Emails go to a shared inbox that nobody watches. Use a paging service for critical alerts.

Comparing Tools: Prometheus vs. Commercial SaaS

Prometheus + Alertmanager is the most common open-source stack. It is powerful but requires you to maintain servers, handle scaling, and write alert rules. For a small team, this can be overhead.

Commercial options (Datadog, New Relic, Sentry) offer easier setup, built-in Node.js instrumentation, and alerting via email, Slack, etc. They cost money per host or per user. Sentry is particularly good for error tracking—it captures stack traces and lets you alert on new errors.

For a solo developer or small SaaS, starting with a simple uptime monitor (like UptimeRobot free tier) plus a hosted error tracker (like Sentry free tier) is often enough. As you grow, add Prometheus for custom metrics.

Cost and Maintenance Considerations

Self-hosted Prometheus is free, but you pay in time: server maintenance, upgrades, and writing alert rules. A small VPS can run it, but if you have many services, you may need a dedicated instance. Commercial tools have predictable per-host pricing (e.g., Datadog charges per host per month), and they handle scaling and updates for you.

Email alerts themselves are cheap—SMTP is a standard protocol. But sending too many emails can get your domain flagged as spam, so keep alert volume low and use a dedicated sender address.

Frequently Asked Questions

What is the best way to get email alerts from Prometheus?

Use Alertmanager with the SMTP receiver. Configure smtp_smarthost, smtp_from, and smtp_auth_username/password in alertmanager.yml. Then create a route that sends alerts to the email receiver. Test with amtool or by firing a test alert.

How often should I check my Node.js health endpoint?

Every 30-60 seconds is typical. More frequent checks (5 seconds) can cause false positives due to transient network blips. For critical services, you can check every 10 seconds, but that increases load on your server and the monitoring service.

Should I alert on 4xx errors?

Generally no, because 4xx errors (like 404 or 401) are client mistakes, not server failures. However, a sudden spike in 401s might indicate a brute-force attack, and a spike in 400s might indicate a bug in your API validation. Alert on 5xx first, then add 4xx alerts with a higher threshold.

What is a good error rate threshold?

It depends on your traffic. For a low-traffic app, even one 500 error can be 10% of requests. Use a window (e.g., 5 minutes) and a threshold like 1% for critical services. For high-traffic apps, 0.1% might be appropriate. Start with 5% and adjust based on your baseline.

Can I use email alerts for critical incidents?

Email is okay for non-urgent issues, but for critical outages, use a paging service (PagerDuty, Opsgenie) that can call or SMS. Email can be delayed and ignored. Use email for warnings and a paging service for pages.

Do I need to monitor the event loop lag?

Yes, if you have CPU-intensive code or use synchronous operations. A high event loop lag means your app is unresponsive even though the process is alive. Use a library like event-loop-stats or the built-in monitorEventLoopDelay in Node.js 10+.

Related

• Choosing a Printer for Occasional Use
• How to Secure Email and Cloud Accounts Against Phishing
• Streaming Latency: Pick the Right Setting