MERLONIX
Sign inStart free

Merlonix vs Prometheus for Agency SSL Monitoring: Why Infrastructure Alerting Is the Wrong Tool

Prometheus comes up regularly when agencies evaluate monitoring options. It is widely used, well-documented, and has a large ecosystem. If you already have Prometheus running for infrastructure monitoring, it is tempting to extend it to cover SSL certificates rather than add another tool.

This post is an honest look at what Prometheus and Alertmanager actually do, what they do not do, and why the tool that works well for monitoring server memory and container uptime is the wrong choice for agency SSL certificate monitoring across a multi-client portfolio.

What Prometheus Is

Prometheus is a time-series metrics database. It collects metrics by scraping HTTP endpoints that expose data in the Prometheus format — CPU usage, memory, request latency, error rates. Alertmanager is Prometheus's companion tool for routing alerts when metrics breach thresholds.

Prometheus was built for infrastructure and application observability: engineers at a company monitoring their own servers, containers, and applications. It is not a domain monitoring tool, an SSL certificate checker, or a DNS validation system.

The distinction matters because the architecture of Prometheus — scraping, metrics, Alertmanager routing rules — maps poorly onto the problems agencies need to solve for SSL and DNS monitoring.

SSL Certificate Monitoring in Prometheus: What You Actually Get

Prometheus can monitor SSL certificates using the blackbox exporter, which probes endpoints and exposes SSL expiry information as a metric. The relevant metric is probe_ssl_earliest_cert_expiry, which is a Unix timestamp of the earliest certificate expiry in the chain.

You can write an Alertmanager rule that fires when this value is within 30 days. In theory, this covers SSL expiry alerting.

In practice, it covers a small fraction of what agencies need from SSL monitoring:

You get: SSL expiry alerts for explicitly configured probe targets.

You do not get:

  • Automatic discovery of subdomains to monitor
  • CNAME integrity validation
  • DNS propagation checks across multiple resolvers
  • Per-client dashboard isolation
  • Vendor/platform status correlation
  • A web UI designed for non-engineers (clients cannot be given access to Grafana)
  • Built-in agency-aware alert routing by client

The CNAME Integrity Gap

The most important thing Prometheus blackbox exporter does not provide is CNAME integrity monitoring.

CNAME integrity is the check that the DNS CNAME for a domain still points at the correct target — the CDN hostname, the hosting platform endpoint, or the certificate authority's validation target. When a CNAME changes, SSL certificate renewal typically fails at the next cycle, but the existing certificate continues serving until it expires.

The failure mode: a client changes DNS provider, the new DNS zone is missing or modifies a CNAME, and the Let's Encrypt or CDN SSL renewal fails silently. The existing certificate serves for up to 90 days. The agency discovers the problem when the certificate expires and the site goes down.

Prometheus has no concept of DNS CNAME integrity. The blackbox exporter probes an endpoint and checks whether the SSL is valid. It does not check whether the CNAME delegation chain is intact. It does not alert when a CNAME target changes. It does not run the DNS check across multiple independent resolvers.

For agencies where most SSL failures are caused by client DNS changes — registrar migrations, IT infrastructure consolidations, CDN provider switches — Prometheus misses the primary failure mode entirely.

The Per-Client Isolation Problem

Prometheus is built for a single organization monitoring its own infrastructure. There is no native concept of "client" or "tenant" in Prometheus.

For an agency managing 30 clients, this means:

  • All 30 clients' probe targets are configured in the same Prometheus instance
  • Alertmanager routes alerts to the same alert pool, which must be manually filtered by client
  • There is no per-client dashboard that shows only that client's SSL and DNS status
  • Clients cannot be given their own view without building a separate Grafana dashboard per client with client-specific filters
  • Alert noise from one client's expired certificate appears alongside alerts from all other clients

Building multi-tenant isolation on top of Prometheus requires significant custom configuration: separate recording rules per client, per-client labels on all probes, Grafana dashboard templates with client variables, and Alertmanager routing trees that separate client alerts into different notification channels.

This is engineering work that scales with the number of clients. At 30 clients it is manageable. At 100 clients it is a maintenance burden.

The Infrastructure Overhead

Prometheus requires infrastructure to run:

  • A Prometheus server with persistent storage for metrics
  • Alertmanager deployment and configuration
  • Blackbox exporter deployment (separate process or container)
  • Grafana for dashboards (another deployment, another database)
  • All of the above require updates, capacity planning, and on-call coverage

Running this stack reliably for production alerting — where a Prometheus outage means you miss SSL expiry alerts — requires the same reliability practices as production infrastructure: redundancy, monitoring the monitor, and regular maintenance.

For an agency that wants SSL and DNS monitoring without building and operating a metrics infrastructure, Prometheus introduces more operational complexity than the problem it solves.

What Merlonix Does Differently for Agencies

Merlonix is purpose-built for agency SSL and DNS monitoring:

CNAME integrity monitoring — Every configured domain is checked for CNAME target correctness on every monitoring interval, across three independent DNS resolvers. DNS changes that will cause SSL renewal to fail are caught at the DNS level, not when the certificate expires.

Per-client isolation — Each client has an isolated monitoring context. Alerts are scoped to the client they belong to. You see each client's SSL and DNS status separately, and the alert routing is pre-configured per client without custom Alertmanager trees.

No infrastructure to operate — Merlonix is a hosted service. No Prometheus deployment, no Alertmanager configuration, no Grafana setup. SSL and DNS monitoring starts in under two minutes.

Vendor status correlation — When a Cloudflare, Vercel, WP Engine, or Fastly incident affects client SSL validation, you see the vendor event alongside the affected client alerts — so you know immediately whether the cause is a client DNS change or a platform-wide incident.

When Prometheus Makes Sense (And When It Does Not)

Prometheus makes sense when you are monitoring infrastructure metrics — server CPU, database query latency, container restarts, request error rates — for systems you own and operate. If you already run Prometheus for your own infrastructure and want to add SSL expiry as one metric among many, the blackbox exporter is a reasonable extension.

Prometheus does not make sense as the primary SSL and DNS monitoring tool for an agency client portfolio. The CNAME integrity gap means the most common agency SSL failure mode — client DNS changes that break renewal — is invisible. The lack of per-client isolation means alert routing requires custom engineering. The infrastructure overhead means you are operating a monitoring stack rather than monitoring clients.

If you are evaluating Prometheus specifically for client SSL certificate monitoring, the honest conclusion is that it is the wrong tool for this job.