Build vs. Buy: In-House TLS Monitoring at Enterprise Scale
Some people roast their own coffee. They buy green beans, weigh them out, use a small drum roaster, time the first crack, listen for the second crack, cool the beans, rest them, grind them fresh, and drink coffee that is genuinely better than what you get at a café.
These people are not wrong. The coffee really is better. The cost-per-cup is lower. But they have also bought a roaster, learned about roast profiles, accepted the morning ritual, and committed several hours a week to the practice. The alternative - buying good beans from a local roaster - gets you 85% of the coffee at 5% of the time.
Building your own TLS monitoring looks a lot like roasting your own coffee.
It can be done well. People have done it well. The result is sometimes better than what you'd buy, especially for specific edge cases. But it costs time you may not want to spend, requires expertise you may not want to maintain, and creates a long-term operational commitment most teams underestimate.
Here's an honest take on when building is the right answer, when buying is, and the hybrid path most teams actually end up on whether they meant to or not.
The honest cost of "build"
When teams talk about building cert monitoring in-house, the initial estimate is usually small. A weekend project. A few hundred lines of Python. Cron, openssl, Slack webhook. Done.
This estimate is correct for the first version. It is wildly wrong for the steady-state cost.
Initial build: 1–2 weeks of one engineer. - Write a script that checks expiry on a list of hostnames. - Add chain validation. Cipher checks. Alerts via Slack. - Maybe a small dashboard. - Tests, documentation, deployment.
Year one: 1–2 hours per week. - Adding new hostnames as services launch. - Debugging false positives (a load balancer with a slightly different cipher list). - Updating when a dependency upgrades. - Handling the case where the script crashed and nobody noticed.
Year two: the original author has moved teams. - New engineer inherits the script. Doesn't fully understand it. Is afraid to change it. - A new failure mode appears (chain break, say). The script doesn't catch it because nobody added the check. - Someone "improves" the script and accidentally disables an alert.
Year three: the script has aged. - The library versions are old. The Slack webhook format changed. The script silently fails. - The team has grown. New services have launched and don't appear in the script's input list. - Coverage is unknown. The dashboard nobody opens looks green.
The HN crowd will tell you, accurately, that Nagios was doing cert checks in 2005. They are right. They will not always tell you what the script looked like in 2015, who maintained it, and whether it was still catching the things people thought it was catching.
When build is the right answer
Build is genuinely the right answer when:
- You have fewer than a hundred certs and they don't change much. The script's surface area stays small. Your infrastructure team enjoys this work and has slack in their schedule. Some teams really do. You have a specific security model that no off-the-shelf product fits. Air-gapped environments, classified environments, environments with unusual compliance constraints. The cost of any external dependency is high - regulated industries, organisations with strict procurement processes where buying anything takes nine months.
In these cases, building is rational. The maintenance cost is real but predictable, and the alternative (a vendor relationship) has its own costs.
When buy is the right answer
Buy is the right answer when:
- You have more than a few hundred certs, or your cert count is growing. Your team is under twenty people and cert ops is not anyone's main job. You want coverage of failure modes beyond expiry - chain, cipher, hostname, revocation, vulnerabilities. Each of these adds meaningful complexity to a build. You want monitoring from outside your network, with multiple geographies, multiple client environments. Building this yourself is a project, not a script. You're under compliance pressure (PCI-DSS, SOC 2, etc.) and need evidence of monitoring you can show an auditor without "we have a Python script" being the answer.
The economics tip toward buy faster than most teams realise. The dollar cost of a focused monitoring tool is usually less than two engineer-weeks per year. Most teams spend more than two engineer-weeks per year keeping their in-house cert checker running.
The hybrid path most teams end up on
The honest truth: most teams that "build" end up partially buying, and most that "buy" still build things around the edges.
The common shape: - Use a managed monitoring tool (TLS Radar, Red Sift, whatever) as the primary external check. - Keep some internal scripts for things the tool can't reach - air-gapped environments, internal services on non-standard ports, specific custom checks. - Use cloud-provider tools (ACM, Cloudflare-managed certs) for what they're designed for. - Pipe everything into a central dashboard or alerting system.
This hybrid is usually better than pure build or pure buy. The buy part covers the 80% case with no maintenance burden. The build part handles the genuinely-bespoke edge cases without trying to replace a whole product.
The trap is thinking the hybrid is something you'll "get to later." Either start with it deliberately or expect a chaotic version of it to emerge anyway.
What "build" actually looks like at scale
If you do build, here's what doing it well looks like at scale (say, 1,000+ certs):
- A dedicated owner - not a side project for whoever's available. A test suite. Yes, for cert monitoring. Version control, code review, deployment pipeline. Not just a script on a server. Multi-region scanning to catch geographic differences. Multiple client TLS stacks for chain testing (because Chrome and old Android disagree). A documented input list that updates from authoritative sources (DNS, cloud APIs, CT logs), not a hand-maintained file. Alerting that routes to teams, with on-call rotations. A way to track ownership at the cert level. A regular review of false positive rates and coverage gaps.
If this list looks like a product, that's because it is one. Many teams build this and then realise they've built half of what a commercial monitor does, at higher cost, with no support contract.
One small ask
The build-vs-buy question is real, and "buy" is not automatically right. But "build" is rarely as cheap as it looks at the start. The path most teams settle into is a hybrid - buy the main monitor, build the specific edge cases. TLS Radar handles the main external monitoring with no scripts to maintain. Free tier covers three domains. If you're three years into a custom cert checker that's slowly drifting, an afternoon on the free tier will tell you what your script is missing.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.