How to Set Up Monitoring and Alerts for Your Product
Implement monitoring and alerting so you know about issues before your customers do. Set up error tracking, uptime monitoring, and performance alerts that keep your product reliable.
Before You Start
- 1
A deployed web application or API
- 2
Access to your application's deployment environment
- 3
At least one notification channel (Slack, email, or PagerDuty)
Step-by-Step Guide
Set up error tracking with Sentry
Install Sentry's SDK in your application (available for every major language and framework). Configure it with your DSN key and set the environment (production, staging). Set up source maps for JavaScript to get readable stack traces. Configure the sample rate (start at 1.0 for full capture, reduce later if volume is too high). Sentry will automatically capture unhandled exceptions with full context: stack trace, request data, browser info, and user details.
Set up Sentry's release tracking to see which deploy introduced new errors. Tag releases with your git commit SHA so you can trace every error to the exact code change.
Configure uptime monitoring for your critical endpoints
Use Better Uptime (or Datadog Synthetic Monitoring) to monitor your most important endpoints: homepage, API health check, login page, and core product pages. Set check intervals to 1 minute for critical endpoints and 5 minutes for secondary pages. Configure alerts to trigger after 2 consecutive failures to avoid noise from transient blips. Set up a public status page so customers can check service status themselves.
Monitor the full user journey, not just the homepage. An API endpoint can be down while your marketing site looks fine. Monitor what matters to your paying customers.
Set up performance monitoring and thresholds
Enable application performance monitoring (APM) to track response times, throughput, and error rates. Datadog APM or Sentry Performance both work well. Set alert thresholds: alert if p95 response time exceeds 2 seconds, if error rate exceeds 1%, or if throughput drops more than 50% from the baseline. Track your slowest endpoints and database queries. Set up weekly performance digests.
Focus on p95 and p99 latency, not averages. Average response time can look great while 5% of your users are experiencing 10-second load times. Percentiles tell the real story.
Configure intelligent alert routing
Send alerts to the right channels based on severity. Critical (site down, data loss risk): PagerDuty or phone call. High (error rate spike, slow responses): Slack alert in a dedicated #incidents channel. Medium (elevated error count, degraded performance): Slack alert in #monitoring. Low (warnings, non-critical issues): email digest. Set up on-call rotation if you have multiple engineers. Use alert grouping to prevent notification storms.
Start with fewer alerts and add more over time. Alert fatigue is real and dangerous: if your team ignores alerts because there are too many false positives, you will miss the real incidents.
Create runbooks and an incident response process
For each alert, create a brief runbook: what the alert means, likely causes, diagnostic steps, and resolution steps. Store these in Notion or your wiki, linked directly from the alert notification. Define your incident response process: (1) acknowledge the alert, (2) assess severity, (3) communicate status to the team, (4) resolve or escalate, (5) write a brief post-mortem for any incident lasting longer than 30 minutes. Keep post-mortems blameless and focused on systemic improvements.
Schedule a monthly 'game day' where you intentionally trigger a failure (kill a service, simulate high load) to test your monitoring and response process. The best time to practice incident response is when there is no real incident.
