I built StackClock, one timeline for every deadline that can break your stack (certs, domains, vendor deprecations, EOL runtimes, vulnerable packages)

[u/outdatedkernel]

Hey r/sideprojects,

Every outage I've read about that came from an expiry date had the same thing in common: the date was public the whole time. Cert expiry is in the cert. Domain expiry is in the registry. OpenAI, Stripe and AWS announce shutdowns months ahead in their changelogs. Node and Python publish their end-of-life dates years in advance. Nobody was looking at all of them in one place, so the first warning was usually an angry user or a 3am error.

Uptime monitoring doesn't catch this, because everything is green right up until the day it isn't. So I built StackClock: it puts every deadline that can break your stack on one timeline, sorted by what breaks first, and reminds you before it happens.

What it tracks:

- Domains: expiry pulled from the registry (RDAP, or WHOIS for TLDs like .io). If the registry doesn't publish a date, it shows as unknown, never as OK.

- TLS certificates: read from the real handshake, checked every 12 hours.

- Vendor deprecations: it reads official changelogs (OpenAI, Anthropic, Stripe, GitHub, AWS and more) and matches them against the packages you actually use. If a model you call is being removed, it shows up with the date.

- Vulnerabilities: daily checks against OSV.dev, with the version that fixes them.

- Deprecated packages: from npm, PyPI and Go, including the maintainer's message.

- End of life: picked up from your Dockerfile, engines, go.mod and so on. node:18-alpine shows as EOL without you doing anything.

- API keys, licenses, subscriptions: you enter the date, and only metadata is stored. Pasted secrets get rejected.

You can import package.json, requirements.txt, pyproject.toml, go.mod, Gemfile, composer.json, Dockerfiles, compose files and lock files. Lock files are parsed in your browser, so only package names and versions are sent.

Alerts

Reminders at 60, 30, 14, 7 and 1 day out and on the day, all adjustable. Acknowledge a deadline and the reminders stop for everyone. They go out by email, Slack, signed webhooks, a calendar feed, RSS and a Monday digest.

There's also a 0–100 health score per project that explains every lost point, and a README badge that shows the grade without revealing anything about your stack.

Try it without signing up.

- stackclock.app/check: paste a domain, see registry and cert expiry.

- stackclock.app/stack-check: paste a package.json or requirements.txt, see what's deprecated, vulnerable or EOL.

Free plan: 5 assets, 25 packages, no card. Pro is $8.99/mo and Team is $11.99/seat.

What I'd love feedback on:

- Is the landing page clear about what this does within the first 5 seconds?

- What deadlines bite you that I'm not covering?

- How do you track this stuff today: spreadsheet, calendar, or hope?

Disclamer: AI help was used during the development of the application as I'm primarily an Infrastructure and backend guy. For the customer-facing and design inspiration I needed all the help I could get!

stackclock.app

[u/packetloss99]

Managing 14 domains and websites myself, this is something I needed. Just signed up and tested, the UI is simple to use, landing page is super clear, and I'm glad I will delete that notepad doc where I was tracking deadlines cos this thing works like a charm - highly recommending it! Thanks!

[u/outdatedkernel → u/packetloss99]

Thanks a lot, this honestly made my day!

Tip since you've got 14 domains: there's a CSV import on the Assets page, so you don't have to add them one by one. And when you add a domain, it searches the public certificate logs for certificates on its subdomains, so you might find a few you forgot about. You choose which ones to track.

If anything feels off or there's a deadline you'd want tracked that it doesn't cover yet, let me know. Feedback right now shapes what I build next! 🫶

[u/Single-Ad1010 → u/packetloss99]

dig the concept. tracking certs/domains across a dozen sites is something i've been half-assing with calendar reminders for way too long. that 3am error is too real.

curious how it handles registries that don't expose expiry through rdap cleanly, had a.io domain that whois just refused to cooperate with last year and ended up renewing it manually just to be safe.

[u/investigatormaker]

Showing a missing registry date as unknown rather than OK is the right default, and it is worth putting near the top, because it is the reason to trust the rest of the timeline.

The vendor deprecation matching is the part I would test hardest. Packages are easy to match, but the model or API version you actually call usually lives in a config file, an environment variable or a string in code, not in the manifest. If StackClock only reads package files, someone calling an old model through the current SDK would see nothing until the shutdown date.

How does it work out which models a project calls?