Prometheus is the metrics backbone of cloud-native infrastructure. It graduated from the CNCF, it ships with every Kubernetes cluster, and its pull-based scrape model plus PromQL have made it the default way teams collect time-series data. If you run containers in production, you probably run Prometheus.
But a recurring myth follows Prometheus around: "we have Prometheus, so we'll know if the site goes down." That sentence conflates two different questions. Prometheus answers "why is this slow or unhealthy, from the inside?" It does not answer "is my site actually up for users, from the outside?" Those are different signals, collected differently, and they fail at different times. Treating Prometheus as a complete monitoring solution is how teams end up with a Grafana dashboard full of green panels while customers stare at a blank page.
This guide covers what Prometheus genuinely catches, where it stops catching things, and why most production teams pair it with an external uptime monitor rather than choosing one over the other.
What Prometheus Actually Is (and Isn't)
Prometheus is three things:
- A time-series database — it stores numeric samples keyed by labels, retained for a configurable window (commonly 15 days, sometimes 6 weeks).
- A scrape engine — it pulls metrics from HTTP
/metricsendpoints on a schedule (typically every 15–60 seconds). - A query language (PromQL) — for slicing, dicing, and alerting on those series.
What it is not:
- Not a dashboard. Visualization is Grafana's job (or your tool of choice). Prometheus ships only a basic expression browser.
- Not an uptime checker. It has no native concept of "is this URL returning 200 from another region." That requires the Blackbox Exporter — a separate component you configure yourself.
- Not a status page. Prometheus has no customer-facing surface. You build that yourself or buy it separately.
- Not external. Prometheus scrapes from wherever it runs — usually inside your cluster or VPC. It sees what your network sees, not what a user in another country sees.
Understanding those boundaries is the whole point. Prometheus is excellent within its scope. The problems start when its scope is assumed to be wider than it is.
What Prometheus Catches Well
Inside its lane, Prometheus is hard to beat.
Infrastructure metrics. With node_exporter on every host, you get CPU per core, memory, disk I/O, filesystem usage, and network throughput. With cAdvisor you get per-container stats. With kube-state-metrics you get Kubernetes object state. This is the layer that tells you why something is struggling.
Application metrics. Instrument your code with a client library and expose counters, gauges, and histograms. Request rate, error rate, latency histograms, queue depth, cache hit ratio — all of it lands in Prometheus as queryable series.
SLO and alerting. Recording rules let you precompute SLOs; alerting rules feed Alertmanager, which handles grouping, inhibition, silencing, and routing to Slack, PagerDuty, email, and webhooks. Done well, this is a powerful alerting layer.
Trend analysis. Because Prometheus stores raw samples with labels, you can ask questions you didn't anticipate at collection time — high-cardinality slicing by service, endpoint, status_code, region, version. That exploratory power is the difference between monitoring and observability.
None of this is in dispute. The question is what isn't on that list.
What Prometheus Misses
Here is the gap that bites teams in production.
1. The outside-in perspective
Prometheus scrapes from inside your network. If your DNS provider has a regional outage, if your CDN edge is degraded in a country, if your origin is reachable from your VPC but timing out for users on a different ISP — Prometheus, sitting next to your services, reports green. The first signal that something is wrong for users often comes from outside, and Prometheus is not positioned outside.
This is the single most common reason teams add an external uptime monitor after a Prometheus-only outage: they were healthy on every internal panel while customers could not reach them.
2. DNS, SSL, and domain expiry
Prometheus does not natively check whether your TLS certificate is about to expire, whether your DNS records have drifted, or whether your domain is weeks from lapsing. You can bolt on exporters, but you are assembling the checks yourself — and the failure mode where the cert expires and nobody noticed is exactly the kind of preventable outage that an external monitor catches by default.
3. Third-party dependencies
If Stripe, Twilio, OpenAI, or your auth provider goes down, your service may degrade even though your own infrastructure is perfect. Prometheus sees your metrics; it does not see theirs. You can model "calls to Stripe are failing" as a metric, but you will not know whether the cause is you or them without an external view of their health.
4. Synthetic checks from multiple regions
The Blackbox Exporter can probe HTTP, TCP, DNS, and ICMP — but it runs from one place by default. Multi-region probing means running Blackbox in several locations, federating or remote-writing the results, and building the dashboards yourself. Every new target is a YAML edit and a reload. There is no "add a URL, get checks from five regions in 30 seconds" experience.
5. A customer-facing status page
Prometheus has no status page. Grafana dashboards are internal tools, not something you hand to customers. When an incident happens, you need a surface that says "we are aware, here is what we know, here is when we will update" — and that surface needs subscriber notifications. That is a separate product, not a Prometheus feature.
6. On-call and incident workflow
Alertmanager routes alerts, but it is not an on-call scheduler, escalation policy, or incident commander. Teams that need "page person A, then B after five minutes, then the team lead" usually wire Alertmanager to PagerDuty or an equivalent — or adopt a platform that bundles the workflow.
The Blackbox Exporter Workaround (and Its Cost)
The honest answer to "can Prometheus do uptime checks?" is: yes, with the Blackbox Exporter, and you will feel every step.
The pattern looks like this:
- Deploy Blackbox Exporter alongside Prometheus.
- For every URL you want probed, add a target to a config file and a scrape job to
prometheus.yml. - Reload Prometheus (or rely on file-based service discovery).
- Write alerting rules in PromQL:
probe_success == 0for down,probe_duration_seconds > 1for slow. - Route those alerts through Alertmanager.
- For multi-region, repeat the exporter in each region and aggregate.
- For a status page, build or buy one separately.
This works. It is also a lot of assembly for what a dedicated uptime monitor does in a few clicks. The Blackbox Exporter is a capable component, but it is a component — not a product. You are the integrator.
That trade-off is fine for teams that already live in Prometheus and want to add a handful of probes. It is the wrong starting point if your actual goal is "know within a minute when my site is down for users, from multiple regions, with a status page and on-call."
Why Most Teams Run Both
The cleanest mental model is two layers that answer different questions:
| Question | Layer | Example tool |
|---|---|---|
| Why is it slow or unhealthy, from the inside? | Metrics / observability | Prometheus + Grafana |
| Is it down for users, from the outside? | External uptime monitoring | A hosted uptime monitor |
Prometheus is the inside-out layer: rich, high-cardinality, great for root cause. External uptime monitoring is the outside-in layer: simple, multi-region, great for detection and customer communication. They fail at different times and they catch different things, so running only one leaves a blind spot.
A typical incident where both earn their keep: an external monitor fires "site unreachable from EU and US" within a minute. You open the Grafana dashboard Prometheus feeds and see memory climbing on the checkout service. The external alert told you that users are affected; Prometheus told you why. Neither signal alone is the full picture.
What to Monitor Externally That Prometheus Can't
A short checklist of signals worth putting outside Prometheus:
- HTTP/HTTPS uptime from at least two regions, on a 1–5 minute cadence
- SSL certificate expiration alerts at 30/14/7 days
- DNS resolution for your apex and key records
- Domain expiry so a registrar lapse does not take you offline
- Third-party API health (payment, email, auth, AI providers) where a vendor outage becomes your outage
- Port/TCP reachability for databases and internal services that should be reachable
- A public status page with subscriber notifications for incidents
- On-call escalation so the right person is paged, not just an alert fired
Each of these is something Prometheus can be made to do with effort, and something a dedicated external monitor does by default.
How Webalert Fits Alongside Prometheus
Webalert is not a replacement for Prometheus. It is the outside-in layer Prometheus does not provide. Where Prometheus scrapes your services from inside, Webalert checks them from multiple regions outside your network — the perspective your users actually have.
What that layer adds on top of a Prometheus stack:
- Multi-region uptime checks (HTTP, HTTPS, TCP, ping) without per-target YAML
- SSL certificate monitoring with expiry alerts before renewal lapses
- DNS and domain monitoring for the records that route your traffic
- Public status pages with subscriber notifications — the customer surface Prometheus lacks
- Incident management for on-call, escalation, and post-incident review
- Smart alerting that confirms downtime from multiple regions before paging, cutting the false alarms that create alert fatigue
- Heartbeat monitoring for cron jobs and scheduled tasks that should phone home
The integration point is straightforward: Webalert can deliver alerts as webhooks, which means you can forward them into Alertmanager or your existing routing so that external downtime and internal metrics land in one alerting view. Two layers, one place to look.
If you already invest in Prometheus for the "why," adding external uptime monitoring closes the "is" gap for a fraction of the engineering time the Blackbox-Exporter-only path costs.
Frequently Asked Questions
Does Prometheus replace an uptime monitor?
No. Prometheus is a metrics backend. It can perform synthetic probes with the Blackbox Exporter, but it does not give you an external, multi-region perspective, a status page, or on-call workflow out of the box. Most teams run both.
Can I use Prometheus as my only monitoring tool?
You can, for internal metrics. But you will be blind to outside-in failures: DNS outages, regional CDN degradation, certificate expiry, and third-party vendor outages that affect your users but not your internal panels.
What does the Blackbox Exporter miss?
Multi-region probing out of the box, a customer-facing status page, subscriber notifications, on-call escalation, and the "add a URL in seconds" experience. It is a component you assemble, not a product you adopt.
Should I send external uptime alerts into Alertmanager?
Yes, if Alertmanager is your alert hub. Forward external downtime alerts as webhooks into Alertmanager (or your router) so internal and external signals land in one view. That keeps a single source of truth for paging.
Is external uptime monitoring redundant with Prometheus?
It is complementary, not redundant. Prometheus tells you why something is unhealthy from the inside; external monitoring tells you whether it is down for users from the outside. They fail at different times, so running only one leaves a blind spot.
Close the Outside-In Gap
Prometheus is the right tool for the inside-out question. For the outside-in question — is my site up for users, right now, from the regions they live in — pair it with an external uptime monitor that ships multi-region checks, SSL and DNS monitoring, a public status page, and on-call in one place.
Start monitoring your site from multiple regions in minutes — free. No agent, no YAML, no self-hosting. Webalert checks your endpoints from outside your network and pages the right person when your users stop reaching you, so your Prometheus stack can focus on the "why."