Alertmanager is one of the most widely deployed pieces of alerting infrastructure in DevOps. It handles deduplication, grouping, silencing, and routing of alerts generated by Prometheus — and it's excellent at exactly that job. But Alertmanager cannot generate an uptime check. It cannot probe an HTTP endpoint, verify an SSL certificate, or confirm that a TCP port is open. It routes alerts that Prometheus fires; it does not create them.
For DevOps teams looking for a simple answer to "is our API reachable right now?", this architectural distinction matters a lot.
What Alertmanager Actually Does
Alertmanager is an alert routing and deduplication engine, not a monitoring agent. It receives alerts from Prometheus (or any compatible sender) and decides: who gets notified, how, when, and how often.
The Prometheus side does the actual monitoring — or rather, the Blackbox Exporter does, as a plugin to Prometheus that actively probes HTTP, TCP, and ICMP targets and exposes results as metrics. Alertmanager then receives those metrics, applies your alert rules, and routes the resulting alerts to Slack, PagerDuty, email, or other receivers.
To do basic HTTP uptime alerting with Alertmanager, you need:
- Prometheus — the metrics system and alert rule evaluator
- Blackbox Exporter — the active prober (separate service, separate config)
- Alertmanager — routes and deduplicates alerts
- Persistent storage, reverse proxy, and deployment manifests for all three
Every component has its own configuration format, its own upgrade path, and its own failure modes. Alertmanager crashing silently means alerts stop routing without any notification that your alerting pipeline is broken.
What Vigilmon Is
Vigilmon is a managed external uptime monitoring platform that replaces the entire Prometheus + Blackbox + Alertmanager stack for one specific problem: knowing whether your endpoints are reachable from the internet.
It probes HTTP/HTTPS endpoints, TCP ports, and SSL certificates from multiple independent geographic regions. Alerts fire only when a quorum of probe nodes independently confirm failure — eliminating false positives from regional network hiccups that a single-probe tool would escalate.
Setup: add a URL, connect Slack or email, done. No YAML. No exporters. No scrape config. No on-call rotation for the monitoring stack itself.
The Configuration Reality
Here is the minimum YAML to configure Alertmanager for routing a single uptime alert to Slack:
# alertmanager.yml
global:
resolve_timeout: 5m
route:
group_by: [alertname, instance]
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
receiver: slack-oncall
receivers:
- name: slack-oncall
slack_configs:
- api_url: https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK
channel: "#alerts"
send_resolved: true
title: '{{ .CommonAnnotations.summary }}'
text: '{{ .CommonAnnotations.description }}'
inhibit_rules:
- source_match:
severity: critical
target_match:
severity: warning
equal: [instance]
That's the Alertmanager side only. You also need Blackbox Exporter configuration, Prometheus scrape config, Prometheus alert rules, and Kubernetes manifests or Docker Compose to run everything. An experienced DevOps engineer should budget 2–4 hours from zero to first verified alert.
Vigilmon's equivalent: sign up, click "Add Monitor", paste a URL and your Slack webhook. Under two minutes.
The Self-Hosted Monitoring Problem
Running your alerting pipeline inside your own infrastructure creates a fundamental monitoring paradox: your monitoring can go down without alerting you.
If Alertmanager restarts in a bad state, you lose alert delivery. If your Prometheus TSDB runs out of disk, scrapes stop. If a Kubernetes node failure takes out Alertmanager and Prometheus together, you have no visibility into your services — and no alert telling you that your monitoring stack is broken.
Watching the watchers requires another layer: a separate "dead man's switch" or external check on your Alertmanager's health endpoint. That's another service to run, configure, and maintain.
Vigilmon's infrastructure is Vigilmon's problem. You get SLA-backed monitoring with no on-call responsibility for the monitoring stack.
Multi-Region Probing vs. Single-Probe Routing
Alertmanager's alert quality is bounded by where your Prometheus/Blackbox Exporter runs. A single deployment in us-east-1 means:
- Regional routing issues may produce false positives (probe-side network failures, not service failures)
- A datacenter connectivity loss might disable both your service and your monitoring simultaneously
- Users in other regions have no independent probe verifying their experience
Achieving multi-region probing with Alertmanager requires deploying Blackbox Exporter in multiple regions, federating Prometheus across them, writing PromQL that correlates cross-region results, and adding Alertmanager inhibition rules to suppress false single-region alerts. This is a significant project.
Vigilmon does this by default. Every check runs from multiple independent nodes before an alert fires.
Feature Comparison
| Capability | Alertmanager (+ Blackbox) | Vigilmon | |---|---|---| | HTTP/HTTPS endpoint probing | ✅ via Blackbox Exporter | ✅ built-in | | TCP port monitoring | ✅ via Blackbox Exporter | ✅ built-in | | SSL certificate expiry alerts | ✅ via Blackbox Exporter | ✅ built-in | | Multi-region consensus probing | ❌ requires multi-region deploy | ✅ default | | Alert routing and deduplication | ✅ Alertmanager (YAML config) | ✅ built-in UI | | Alert silencing | ✅ Alertmanager silences | ✅ built-in | | Cron job heartbeat monitoring | ❌ | ✅ built-in | | Public status page | ❌ requires add-on | ✅ included | | Infrastructure to operate | 3+ services | None (SaaS) | | Setup time for basic uptime alert | 2–4 hours | Under 2 minutes | | Alert if monitoring stack breaks | Requires extra tooling | N/A (managed) |
When to Use Each
Use Alertmanager when:
- You're already running a Prometheus ecosystem for application metrics
- You need PromQL-based alerting on custom metrics (error rate, queue depth, latency percentiles)
- You have Kubernetes cluster-level monitoring via kube-state-metrics and node-exporter
- Your team has existing Prometheus/Alertmanager expertise
Use Vigilmon when:
- You need to know if your public endpoints are reachable from the internet
- You want uptime, SSL, and TCP monitoring without new infrastructure to operate
- You want multi-region consensus to eliminate false positives
- You want a status page your customers can check without building one
Use both: A mature production stack uses Prometheus + Alertmanager for internal application metrics and Vigilmon for external reachability verification. Internal metrics can look healthy while DNS is broken, a CDN is misconfigured, or a TLS certificate has expired. External monitoring closes that blind spot.
Summary
Alertmanager is a powerful and flexible component of the Prometheus alerting ecosystem — for teams that are already running Prometheus. It was designed to route and deduplicate alerts, not to generate them from scratch.
For DevOps teams that want external uptime monitoring without operating a three-component self-hosted stack, Vigilmon is purpose-built: managed probing, multi-region consensus, alert routing, SSL monitoring, and status pages in a single SaaS platform.
Get started at vigilmon.online — 5 monitors free, no credit card, up and running in under 2 minutes.
Tags: #alertmanager #prometheus #devops #uptime #monitoring #sre #alerting #observability