Open Source SSL Monitoring for Agencies: Why Self-Hosted Falls Apart at Portfolio Scale
Open source SSL monitoring tools are technically capable. Zabbix can monitor SSL certificates at scale. Nagios has SSL check plugins that have been production-tested for over a decade. Prometheus paired with the Blackbox Exporter gives you flexible metric collection and alerting. CertBot handles certificate renewal and can be configured to send expiry notifications. A competent engineer can build a capable SSL monitoring stack from these tools at near-zero licensing cost.
The question is not whether these tools work. It is whether they make operational sense for a marketing agency managing a client portfolio.
They were built by engineering teams, for engineering teams, managing their own infrastructure. The mental model embedded in their architecture — and in their documentation, their configuration syntax, and their alerting models — is that you own the infrastructure you are monitoring. You have a server you can SSH into. You control the DNS zones. You manage the certificate renewal process. The monitoring exists to keep you informed about systems you are responsible for building and maintaining.
Marketing agencies work in a different context. Your clients own their infrastructure. Their domains, their hosting accounts, their SSL certificates are not yours to configure or renew. You are monitoring external systems, not internal ones. That distinction matters more than it initially appears.
What Open Source SSL Monitoring Actually Requires
Setting up a self-hosted SSL monitoring stack is not a one-afternoon task. Here is what it actually involves, in honest terms.
A server to run it on. Zabbix, Nagios, and Prometheus all require a server. This can be a VPS — a small one is sufficient — but it needs to be provisioned, secured, maintained, and paid for. A basic DigitalOcean or Linode instance at $6-12/month is the floor. You also need to factor in the time to provision it correctly: firewall rules, OS hardening, backup configuration.
Initial configuration. Prometheus with Blackbox Exporter requires writing a configuration file that specifies each target, the module to use, the scrape interval, and the alerting thresholds. Nagios requires creating check definitions for each host and service. Zabbix requires adding hosts and linking them to templates. None of this is automatic — every domain you want to monitor requires a configuration entry.
Alert routing setup. Monitoring without alerting is just dashboards. Getting SSL expiry alerts out of any open source tool requires configuring an alert manager. In Prometheus, this means writing AlertManager configuration with routing rules and receiver definitions. In Nagios, it means configuring contact definitions and escalation policies. In Zabbix, it means setting up media types and user notification preferences. This is not especially complex, but it requires time to do correctly.
Ongoing maintenance. Open source monitoring stacks require updates. Security patches for the monitoring server. Version upgrades for the monitoring software. Breaking changes between versions that require configuration adjustments. Plugin compatibility issues. Every hour spent maintaining the monitoring infrastructure is an hour not spent on client work.
Documentation and knowledge transfer. A self-hosted monitoring stack owned by one engineer is a dependency that the agency inherits. If that engineer leaves, or is simply unavailable, the monitoring stack becomes a black box. Maintaining runbooks for a monitoring system adds another category of ongoing maintenance.
Why This Breaks Down for Agencies
The operational overhead described above is manageable for an engineering team that considers infrastructure management part of its core function. For a marketing agency, it is overhead without a natural owner.
Client domains are not your infrastructure. When a client's SSL certificate expires, you did not provision it. When a client adds a domain, you cannot automatically detect it and add it to your monitoring stack — someone has to do that manually. When a client leaves, you have to manually remove their domains from your configuration. Every client change is a configuration event.
In a self-hosted Prometheus stack, adding a new client domain means editing a configuration file, reloading the Prometheus configuration, and verifying the target is being scraped. Removing a client means reversing that process. Across a portfolio of 30 clients, each with an average of 3 domains, that is 90 configuration entries to manage — and any client change is a potential configuration mistake.
Alert routing per client requires per-client configuration. If you want SSL expiry alerts for Client A to go to Client A's contacts, and SSL expiry alerts for Client B to go to Client B's contacts, you need routing rules that separate these flows. In Prometheus AlertManager, this means label-based routing rules. In Nagios, it means contact groups per client. This is achievable, but every new client adds configuration complexity. At 20 clients, maintaining this correctly is a dedicated responsibility.
There is no client-facing report output. Prometheus gives you dashboards. Nagios gives you status screens. Neither produces a branded, client-ready monthly report showing SSL certificate status, expiry dates, DNS health, and uptime history. Building that report from dashboard data requires either a custom dashboard export, a manual assembly process, or writing a script that queries the Prometheus API and generates a PDF. All of these options represent significant ongoing labour per client per month.
You bear all the operational responsibility. With a SaaS monitoring tool, when the monitoring infrastructure has a problem, the vendor resolves it. With a self-hosted stack, you are the vendor. Monitoring downtime is your downtime. Missed alerts because of a configuration error are your missed alerts. At 2am when a client's SSL certificate is about to expire and the alert was never sent because of a misconfigured AlertManager route, the accountability is yours.
The Real Cost Calculation
The appeal of open source SSL monitoring is the licensing cost: zero. But licensing cost is not total cost.
Consider a realistic scenario: an agency with 25 clients, each with 2-3 domains to monitor, adding one or two new clients per month.
Initial setup time. A competent engineer setting up Prometheus with Blackbox Exporter, AlertManager, and a basic Grafana dashboard for SSL monitoring will spend 8-16 hours on initial configuration, testing, and validation. At an internal hourly rate of £60-80/hour, that is £480-£1,280 in initial setup cost.
Per-client onboarding time. Each new client requires adding domains to the Prometheus scrape configuration, writing or updating AlertManager routing rules, and verifying the configuration is correct. Conservatively, 30-60 minutes per client. At 2 new clients per month, that is 1-2 hours of engineering time monthly.
Monthly maintenance. Keeping the server patched, handling version upgrades, reviewing monitoring gaps, and responding to false positives: conservatively 2-4 hours per month.
Monthly report assembly. If you are promising clients a monthly monitoring report, and you have no automated report output, someone assembles that report manually. At 30 minutes per client per month across 25 clients, that is 12.5 hours per month — before accounting for formatting, branding, and delivery.
The total ongoing monthly cost — before accounting for the server itself — is roughly 15-20 hours of engineering or operations time. At £60/hour, that is £900-£1,200/month in internal labour costs.
A SaaS SSL monitoring tool purpose-built for agencies, at £49-99/month, eliminates the server maintenance, the per-client configuration overhead, and the report assembly labour. The break-even calculation is straightforward.
When Open Source Makes Sense
There are legitimate scenarios where open source SSL monitoring is the right choice.
Internal engineering teams managing their own infrastructure. If you are a company with a DevOps function that already operates Prometheus for application monitoring, adding SSL checks via Blackbox Exporter is a natural extension. The infrastructure already exists. The expertise already exists. The incremental cost of SSL monitoring in this context is low.
Agencies with a dedicated DevOps employee. If your agency has a DevOps or infrastructure engineer who owns the monitoring stack as part of their role, self-hosted monitoring is operationally viable. The key is having a named owner who maintains the stack and treats it as a product, not a tool that gets configured once and forgotten.
Small portfolios with low client turnover. If you are monitoring 5-8 static client domains with minimal change, the configuration overhead is manageable. The economics shift when you start adding and removing clients regularly, or when you need per-client alert routing and reporting.
Not for operations-led agencies managing external client portfolios. If your agency's monitoring is owned by account managers or operations staff rather than engineers, open source tools are not the right fit. The configuration complexity requires engineering skills that are not typically part of account management roles, and the ongoing maintenance burden falls in the wrong place.
What Agencies Need Instead
The requirements that open source tools fail to address efficiently are exactly what purpose-built agency monitoring tools are designed for: per-client architecture out of the box, automated alert routing per client, automated branded report output, and no server infrastructure to maintain.
Merlonix is structured around client workspaces as the primary unit. Each client has their own workspace, their own SSL and DNS monitors, their own alert routing, and their own automated monthly report. Adding a client is a UI operation, not a configuration file edit. Removing a client cleans up automatically. Reports are generated and delivered without manual assembly.
The total cost — tool cost plus operational overhead — is lower than a self-hosted open source stack for any agency managing more than 10 active clients.
→ SSL Monitoring Buyer's Guide for Agencies