I Let a SSL/TLS Certificate Expire Because My Crontab Was on the Wrong Server. So I Built CertChime.

It wasn't a major outage. No revenue lost, no angry emails from investors. But a user reached out saying they couldn't access a feature, and when I dug in, I found the SSL certificate for one of our quieter services had expired — silently, without a single warning.

The reason was embarrassingly mundane: the cron job that checked certificate expiry was running on a server I'd since migrated away from. When I moved things over, I forgot to bring the cron job with it. No alerts fired. No one noticed. Until a user did.

I got lucky. It was a low-traffic service.

But it stuck with me.

The Fix I Tried First

My first instinct was to just use an existing monitoring tool. I'd heard of UptimeRobot, Better Uptime, Datadog. But when I opened them up, I ran into the same wall every time: I had to create an account, set up a workspace, configure a project, and wade through dashboards built for monitoring uptime, response times, error rates — the whole infrastructure picture.

That's not what I wanted.

I'm not responsible for uptime on most of the services I touch. I just wanted to know: is this certificate going to expire soon? That's it. One thing.

The tools I found treated SSL monitoring as a checkbox inside a much larger product. Which makes sense for teams running full observability stacks. But for me — a developer maintaining a handful of services after hours — it felt like buying a car to check the oil.

So I Built the Minimal Version

I'm a Next.js developer. I work on this kind of thing at night, after my day job. I gave myself permission to build something small and useful, not something that would compete with Datadog.

The core idea: type a domain, see your certificate status instantly, leave your email, get reminded before it expires. No account. No dashboard you have to log into. No noise.

I called it CertChime.

Here's what it does:

• Instant TLS certificate check — expiry date, issuer, days remaining

• Email reminders at 30, 14, 7, and 1 day before expiry

• A public status page you can share with clients or teammates

• A simple API (curl https://certchime.com/api/check?domain=yourdomain.com) - no API key required

• A simple subscribe API (curl -X POST https://certchime.com/api/subscribe -H "Content-Type: application/json" -d '{"email":"[email protected]","domain":"example.com"}') - automate monitoring without touching the UI

• Multi-domain workspace management

Here's what it doesn't do: monitor uptime, track response times, alert on errors, manage incidents, or require you to set up anything before you can use it.

That last part was intentional. The zero-signup flow for a quick check was something I wanted personally. If you just want to know when a cert expires, you shouldn't have to create an account to find out.

What Took 1 Months of Nights

The core check was fast to build — a real TLS handshake running on AWS Lambda, fronted by Cloudflare.. The harder parts were:

Reliable email delivery. Reminders are the whole point. If the emails don't land, the product doesn't work. Getting DNS records right, warming up sending reputation, making sure 30-day warnings actually fire — this took more iteration than I expected.

The public status page. I wanted something you could send to a client that looked professional and was scoped specifically to certificates, not a generic uptime page. This became one of the features I'm most happy with. A web agency managing 20 client sites can now send each client a link that says "here's the health of your SSL certificate" — without the client needing an account either.

Not adding too much. The hardest engineering decision was what to leave out. Every time I thought "maybe I should add Slack notifications," I asked myself: would I have needed this to avoid my original problem? Usually the answer was no.

What I Haven't Built Yet (and Why I'm Shipping Anyway)

Brand customization on status pages — not done. Weekly digest emails — not done. Multi-channel notifications — not done.

I spent a while using these missing features as reasons not to launch. Then I realized I was imagining a hypothetical user who needed all of those things, rather than the real user I actually understand: someone like me, who just wants to stop forgetting about certificate expiry.

The features I have are complete. The features I don't have aren't blockers for the person this is built for.

So I'm shipping it.

Why This Niche, When Bigger Tools Exist

Someone will read this and think: Datadog does this. UptimeRobot does this. Why build it?

A few reasons:

The big tools treat SSL as one checkbox in a hundred. That means the UX around it is an afterthought. The public status page scoped to certificates doesn't exist in those tools. The zero-signup instant check doesn't exist. The curl-friendly API doesn't exist.

More importantly: the big tools are priced and scoped for teams running full infrastructure. A solo developer maintaining side projects, or a small web agency managing client sites, doesn't need 90% of what those tools offer. They need the 10% that's specifically about certificates, done well.

That gap is real. I know because I lived it.

The Honest Part

I don't know if this becomes a business. I'm not quitting my job over it. I built it because I needed it, and because I thought other people might too.

If it gets a few hundred users and covers its own hosting costs, that's a good outcome. If someone tells me it saved them from an embarrassing outage, that's a great outcome.

What I do know is that the problem is real, the solution is specific, and the product works. That feels like enough to put it in front of people.

If you manage SSL certificates and you're tired of finding out they expired from a user, give CertChime a try. No signup required to check your first domain.

And if you've shipped something in a crowded space and have thoughts on what actually worked for distribution — I'm genuinely curious. Drop it in the comments.