# website monitoring
How to Set Up Monitoring for Staging vs Production Environments
Most teams set up monitoring for production and stop there. Some never set up monitoring for staging at all. Both approaches leave gaps. The right strategy treats staging and production as separate monitoring contexts with different requirements, alert thresholds, and notification paths.
Why Staging Needs Monitoring Too
Staging environments have real failure modes that monitoring catches:
- Pre-release validation — a deployment to staging that breaks the application is caught before it reaches production
- Integration testing — staging environments often connect to sandbox versions of third-party APIs; failures in these integrations are worth knowing about
- SSL and DNS — staging environments on custom domains (e.g.,
staging.yourapp.com) have their own SSL certificates and DNS configuration that can break - Deployment pipelines — monitoring staging availability tells you whether a deployment completed successfully
The difference is what you do with staging failures. A staging outage doesn't need to wake up an on-call engineer at 2am — but it should appear in your monitoring dashboard and generate a low-priority notification.
Production Monitoring Configuration
Production monitoring should be aggressive:
Check Frequency
- Critical endpoints (checkout, authentication, API) — every 1 minute
- General pages — every 5 minutes
- See how to choose monitoring check frequency for detailed guidance
Alert Routing
- Immediate SMS for any production downtime affecting core user flows
- Slack notifications to a
#monitoringor#incidentschannel - Email as backup
- Defined on-call rotation for overnight and weekend coverage
Multi-Location Checks
- Check from multiple geographic locations to catch regional outages
- A failure from all locations = infrastructure problem
- A failure from one location = possible network or CDN issue in that region
Content Matching
- Verify key page content, not just HTTP 200 responses
- A page that returns 200 with an error message is caught by content matching but not by status code monitoring
SSL and Domain
- Monitor SSL certificate expiry with 30+ day advance alerts
- Monitor domain expiry
- Alert immediately on any DNS record changes
Staging Monitoring Configuration
Staging monitoring should be lower priority but still present:
Check Frequency
- Every 5–10 minutes is sufficient
- No need for 1-minute intervals on staging
Alert Routing
- Slack notification only — no SMS, no on-call
- Route to a
#stagingchannel or similar low-priority channel - Consider suppressing overnight and weekend alerts for staging
No Multi-Location Required
- Single-location checks are sufficient for staging
- Staging is typically not geographically distributed
Pausing Alerts During Deployments
Most monitoring tools support maintenance windows. Set a maintenance window during scheduled staging deployments to suppress false alerts during the deployment process. See maintenance windows for configuration.
SSL on Staging
- Monitor staging SSL certificates — they expire just like production
- Let's Encrypt certificates on staging subdomains fail silently without monitoring
- Lower alert lead time is acceptable (14 days rather than 30)
Common Mistakes
Treating staging failures as production-priority alerts
If staging alerts fire at the same severity as production, teams learn to ignore the noise — which means they ignore production alerts too. Staging alerts must be clearly differentiated.
Monitoring production but not staging, then being surprised by deployment failures
"It passed on staging" is only useful if you know staging was actually working before the test. Without staging monitoring, you don't know the baseline.
Sharing SSL certificates between staging and production
Staging should have its own SSL certificate on its own subdomain. Sharing certificates creates unnecessary coupling.
Not suppressing alerts during scheduled maintenance
A deployment that takes staging briefly offline generating a flood of alerts trains teams to dismiss alerts. Use maintenance windows.
Environment Naming Conventions for Monitors
Name your monitors clearly to distinguish environments at a glance:
[PROD] Homepage - yourapp.com
[PROD] API Health - api.yourapp.com/health
[STAGING] Homepage - staging.yourapp.com
[STAGING] API Health - staging-api.yourapp.com/health
This convention makes your monitoring dashboard readable and ensures the right person investigates the right alert.
Get Started
Domain Monitor lets you create separate monitors for staging and production with independent alert configurations, check intervals, and notification contacts. Create a free account.
Related Articles
More posts
What Is a Subdomain Takeover and How to Prevent It
A subdomain takeover lets an attacker claim your subdomain by exploiting dangling DNS records. Learn how it happens, real-world examples, and how DNS monitoring detects it.
Read moreWhat Is Mean Time to Detect (MTTD)?
Mean time to detect (MTTD) measures how long it takes to discover an incident after it starts. Reducing MTTD is one of the highest-leverage improvements in reliability engineering.
Read moreWhat Is Black Box Monitoring?
Black box monitoring tests your systems from the outside, the way users experience them — without access to internal code or infrastructure. Learn how it works and when to use it.
Read moreSubscribe to our PRO plan.
Looking to monitor your website and domains? Join our platform and start today.