Everything expires, and nothing tells you

The least glamorous lesson here

It prevents more downtime than anything in this course except backups.

A live product is held up by a dozen things that have expiry dates. None of them fail because of load or bugs. They fail on a specific day, usually to nobody’s surprise except everybody’s.

The list

The domain. The one that ends the product rather than degrades it. The usual sequence: the card on file expired, auto-renew failed silently, the notification went to an address nobody reads. After expiry there is typically a grace period of about 30 days during which you can renew normally, then a redemption period where recovery costs a restore fee: commonly $80 to $150, against a renewal of $11. After that it can be registered by anyone, and domains that have carried traffic are bought within minutes.

Register for several years at once, turn on auto-renew, keep the card current, and turn on the registrar’s transfer lock (clientTransferProhibited) so nobody can move it away.

The TLS certificate. Covered in module one. Worth repeating here because Let’s Encrypt no longer sends expiry warnings, so a broken renewal is now completely silent until the site goes red.

OAuth client secrets and API keys. Google OAuth client secrets, Apple’s signing keys, some payment provider keys: several have hard expiry dates measured in months. When they expire, sign-in stops working for everybody at once, on a date that was known a year in advance.

Every card on file. One card, five vendors, one expiry date. When it expires you get five failures across a week, in the order the vendors happen to bill.

Free tiers and trial credits. A cloud trial with $300 of credit ends. A “free for 12 months” tier starts charging. A database free tier changes its terms. This is the availability half of what the billing lesson covered: some services suspend rather than bill.

Deprecated APIs with a sunset date. The provider emailed the address on the account, which is the personal address of somebody who left in March.

Your own monitoring’s free tier. The check that would have told you stopped running, quietly, and its silence looks exactly like health.

The fix is one file and one calendar

Nothing sophisticated. A RENEWALS.md in the repository:

domain addaly.com   registrar: X   renews 2027-03-14  auto-renew ON  card ending 4412
TLS                 Let's Encrypt  auto, 90d          monitor: cert-expiry check
Google OAuth secret expires 2027-01-08                rotate procedure: docs/…
Cloud account       card ending 4412                  expires 06/28
Mail provider       free tier 300/day                 review 2027-01

Then a calendar event 30 days before each, and (this is the part that makes it work) use a role address, not a person’s. Every vendor account registered to ops@yourdomain, forwarded to whoever is currently responsible. Personal addresses are how the sunset email reaches nobody.

Two checks worth automating today

# domain expiry
whois addaly.com | grep -iE 'expir'

# certificate expiry
echo | openssl s_client -connect addaly.com:443 -servername addaly.com 2>/dev/null \
  | openssl x509 -noout -enddate

Wrap both in a scheduled job that alerts at 45 days for the domain and 21 for the certificate. It is twenty lines and it retires two of the most avoidable outages there are.

The habit underneath

When you add anything that has a date (a key, a card, a plan, a contract) the same moment you add it, write the line in the file and make the calendar entry. Not later. Later is where these live until they expire.

This is a small discipline that reads as bureaucratic and is not. It is the difference between a product that quietly keeps working and one that has a bad Tuesday every few months for reasons that were all knowable in advance.