DEV Community

Vigilmon
Vigilmon

Posted on

How to Set Up On-Call Alerts with Vigilmon (No PagerDuty Required)

#monitoring #devops #alerting #oncall

How to Set Up On-Call Alerts with Vigilmon (No PagerDuty Required)

On-call alerting is what separates a monitoring setup from a production-ready monitoring setup. Knowing your site is down is half the battle — the other half is making sure the right person gets notified at the right time, on the right channel, without alert fatigue.

This guide shows how to configure effective on-call alerting with Vigilmon — including escalation paths, noise reduction, and multi-channel delivery.

The Problem with Basic Monitoring Alerts

Most monitoring tools send one email when something goes down. The problems:

  1. Email is too slow — you check email every few hours, not every minute
  2. No escalation — if the primary person misses the alert, nothing happens
  3. Alert storms — a single outage triggers 50 emails (one per check) and you start ignoring them
  4. False positives — a 10-second blip fires the same alert as a 2-hour outage
  5. No recovery notification — you don't know when the issue resolves

Step 1: Set Up Multi-Channel Alerting

Vigilmon supports multiple alert channels. Configure at least two for on-call coverage:

Email (for asynchronous awareness)

Add your email in Settings → Alert Channels → Email. This is the paper trail — every incident gets documented.

Slack (for fast team notification)

  1. Go to Settings → Alert Channels → Slack
  2. Add a Slack webhook URL (create one in your Slack workspace → Apps → Incoming Webhooks)
  3. Point it to your #incidents or #alerts channel

Now both email and Slack fire when a monitor goes down.

Step 2: Reduce False Positives with Confirmation Checks

Vigilmon checks from multiple regions and can require failures from multiple locations before alerting. This eliminates "blip" false positives.

Configure in Monitor Settings:

  • Check interval: 60 seconds (or 30s for critical services)
  • Confirmation before alert: require 2 consecutive failures before alerting
  • This means: a single bad check doesn't page anyone. Two consecutive bad checks from the same region fires an alert.

For critical services (payment processing, authentication), set confirmation to 1 — you want faster alerting even at the cost of an occasional false positive.

Step 3: Use Webhooks to Route to On-Call Tools

If your team uses a dedicated on-call tool (Opsgenie, VictorOps, Squadcast), use Vigilmon's webhook channel:

  1. Go to Settings → Alert Channels → Webhook
  2. Enter your Opsgenie/VictorOps webhook URL
  3. Vigilmon sends a structured JSON payload on each incident

Example Vigilmon webhook payload:

{
  "event": "monitor_down",
  "monitor": {
    "name": "Production API",
    "url": "https://api.yourapp.com/health",
    "status": "down"
  },
  "downtime_started_at": "2026-08-04T10:23:00Z",
  "duration_seconds": 120
}
Enter fullscreen mode Exit fullscreen mode

Your on-call tool receives this and handles rotation, escalation, and acknowledgement.

Step 4: Configure Different Alert Policies per Monitor

Not all services are equally critical. Set up tiered alerting:

Tier 1 (P1 — immediate page):

  • Payment processing endpoint
  • Authentication/login API
  • Main web application homepage

Alert config: 1 confirmation check, email + Slack + webhook (PagerDuty/Opsgenie)

Tier 2 (P2 — alert within 5 minutes):

  • Admin dashboard
  • Background job health endpoints
  • API endpoints used by < 20% of users

Alert config: 2 confirmation checks, email + Slack

Tier 3 (P3 — awareness only):

  • Staging environment
  • Non-critical tooling
  • Dev domains

Alert config: 3 confirmation checks, email only

Step 5: Set Up Recovery Notifications

Vigilmon sends a recovery alert when a monitor comes back up. Configure this to fire to the same channels as the down alert.

This is critical for on-call workflows:

  • Down alert → engineer investigates
  • Recovery alert → engineer knows the issue resolved (and can note whether it was their fix or self-healing)

Step 6: Personal Alerting via Email Rules

For individual on-call engineers:

  1. Forward Vigilmon alerts to a dedicated on-call email alias (oncall@yourcompany.com)
  2. Set that alias to forward to the current on-call engineer
  3. On-call engineer adds a mobile email notification rule for that alias

This gives you on-call rotation without needing PagerDuty's licensing fee.

Sample On-Call Alert Flow 

[10:23:05] Vigilmon: Production API fails check #1 (region: US-East)
[10:24:05] Vigilmon: Production API fails check #2 (region: US-East) → ALERT FIRES
[10:24:05] Email sent → oncall@company.com
[10:24:05] Slack message → #incidents ("🚨 Production API is DOWN")
[10:24:05] Webhook → Opsgenie (creates incident, pages on-call engineer)
[10:26:00] Engineer acknowledges in Opsgenie
[10:31:00] Engineer deploys fix
[10:32:05] Vigilmon: Production API passes check #1 → RECOVERY FIRES
[10:32:05] Email + Slack: "✅ Production API is back UP (downtime: 8 min)"
Enter fullscreen mode Exit fullscreen mode

Conclusion

Effective on-call alerting doesn't require expensive tooling — it requires the right configuration. Vigilmon's multi-channel alerting, confirmation checks, and webhook support give you a production-grade on-call setup without PagerDuty's price tag.

Set up on-call monitoring with Vigilmon — free to start

Top comments (0)