DEV Community

Vigilmon
Vigilmon

Posted on

How to Monitor Multiple Environments (Dev, Staging, Prod) with Vigilmon

#devops #monitoring #staging #production

Every serious application runs in multiple environments. But most teams only monitor production - and discover staging is broken when they try to demo to a client. This guide shows how to set up monitoring for all your environments with Vigilmon.

Why Monitor Non-Production Environments?

Staging: Broken staging costs you demo time, delays QA sign-offs, and causes embarrassing client meetings. If staging is silently down, your team wastes hours debugging "environment issues."

Development: Less critical, but a broken dev environment slows your whole team.

Production: Obvious - but production-only monitoring means you only catch problems when real users are already affected.

Preview/PR environments: Ephemeral but important - a broken preview URL wastes reviewer time.

The Multi-Environment Monitoring Strategy

Here's the practical approach:

Environment Check Interval Alert Channel On-Call?
Production 1-3 minutes Slack + SMS + Email Yes
Staging 5-10 minutes Slack + Email No
Development 15-30 minutes Email only No

Setting Up Multi-Environment Monitoring in Vigilmon

Step 1: Create your account

Sign up free at vigilmon.online. The free tier supports unlimited monitors.

Step 2: Organize with labels or naming conventions

Use a consistent naming pattern for your monitors:

[PROD] api.yourapp.com
[PROD] app.yourapp.com
[PROD] app.yourapp.com/health
[STAGING] staging-api.yourapp.com
[STAGING] staging.yourapp.com
[DEV] dev.yourapp.com
Enter fullscreen mode Exit fullscreen mode

This makes your dashboard scannable at a glance.

Step 3: Set different check intervals per environment

  • Production: 1-3 minute intervals (catch issues fast)
  • Staging: 5 minutes (balance cost vs detection speed)
  • Development: 15-30 minutes (just enough to know it's reachable)

Step 4: Configure separate alert channels

In Vigilmon, create different notification policies per environment:

Production policy:

Alert after: 2 consecutive failures
Notify: Slack #incidents + SMS + Email
Escalate: After 10 minutes unacknowledged
Enter fullscreen mode Exit fullscreen mode

Staging policy:

Alert after: 3 consecutive failures  
Notify: Slack #dev channel + Email
No escalation (not user-facing)
Enter fullscreen mode Exit fullscreen mode

Dev policy:

Alert after: 5 consecutive failures
Notify: Email only
No escalation
Enter fullscreen mode Exit fullscreen mode

What to Monitor Per Environment

Production: Full coverage 

# Core application
https://yourapp.com              - Homepage
https://app.yourapp.com/login    - Auth flow
https://api.yourapp.com/health   - API health

# Critical user paths
https://yourapp.com/checkout     - Revenue path
https://yourapp.com/dashboard    - Core product

# Infrastructure
SSL expiry monitoring            - All domains
Enter fullscreen mode Exit fullscreen mode

Staging: Functional coverage 

https://staging.yourapp.com           - App loads
https://staging-api.yourapp.com/health - API health
Enter fullscreen mode Exit fullscreen mode

Skip individual feature-page monitors in staging - focus on "is it up and can auth work?"

Development: Minimal coverage 

https://dev.yourapp.com               - Just check it's reachable
Enter fullscreen mode Exit fullscreen mode

Monitoring Ephemeral Preview Environments

If you use Vercel, Netlify, or Railway preview deployments, you can:

  1. Use Vigilmon's API to create monitors programmatically when a PR is opened
  2. Delete monitors when the PR closes

Here's a GitHub Actions example:

name: Create Preview Monitor
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  create-monitor:
    runs-on: ubuntu-latest
    steps:
      - name: Create Vigilmon monitor
        run: |
          curl -X POST https://vigilmon.online/api/v1/monitors \
            -H "Authorization: Bearer ${{ secrets.VIGILMON_API_KEY }}" \
            -H "Content-Type: application/json" \
            -d '{
              "url": "${{ github.event.deployment_status.target_url }}",
              "name": "PR-${{ github.event.number }} Preview",
              "interval": 10
            }'
Enter fullscreen mode Exit fullscreen mode

Avoiding Alert Fatigue in Multi-Environment Setups

The biggest risk with monitoring multiple environments is alert noise:

  1. Silence staging alerts at night: Your staging environment might restart automatically - don't get paged at 2am for a staging cron restart
  2. Batch non-production alerts: Instead of immediate notification, send a daily summary for dev/staging issues
  3. Use separate Slack channels: #prod-alerts (high priority) vs #staging-alerts (low priority)

Status Pages Per Environment

Consider creating separate public status pages for:

  • Public status page (status.yourapp.com): Production only, customer-facing
  • Internal status page: All environments, team-facing

Vigilmon supports multiple status pages, letting you configure which monitors appear on each.

Sample Multi-Environment Dashboard

After setup, your Vigilmon dashboard should show:

PRODUCTION (3 monitors)
? yourapp.com           99.98%   287ms
? api.yourapp.com       99.97%   134ms  
? app.yourapp.com       99.95%   423ms

STAGING (2 monitors)
? staging.yourapp.com   99.72%   651ms
? staging-api           99.80%   312ms

DEVELOPMENT (1 monitor)
? dev.yourapp.com       98.10%   891ms
Enter fullscreen mode Exit fullscreen mode

Seeing staging at 99.72% uptime might prompt you to investigate why it restarts more often than production.

Start Monitoring All Your Environments

Set up free multi-environment monitoring at vigilmon.online. Unlimited monitors, multi-region checks, and a dashboard that shows all your environments at once.

Your clients deserve to see a working staging demo. Your team deserves to know when dev is broken before they spend an hour debugging their local setup.

Top comments (0)