Ask any ops lead about their worst outage and there is a decent chance the answer involves something that simply ran out. A certificate, a licence, a support window, a quota that reset. The follow-up question is usually “how did nobody see that coming?” and the honest answer is that plenty of people could have. The date was always there. This post takes six comfortable beliefs that stop teams from keeping a proper key-dates calendar and takes them apart one at a time.
Myth 1: “Automation handles renewals, so we don’t need to track them”
Automation is great, and you should use it. But automated renewal is a process, and processes break. A validation method changes, a DNS record gets moved, an API token behind the renewal job expires, or the job itself is disabled during a migration and never turned back on. Each of these has taken down real systems.
The calendar does not compete with automation; it audits it. For every automated renewal, add an entry on the expiry date with a reminder a few weeks earlier that reads “confirm the renewal actually ran.” Confirming takes a minute. Discovering a silent failure on expiry day takes an incident.
Myth 2: “Our monitoring will warn us”
Monitoring tells you what is happening now. Some of it will tell you a certificate expires within a threshold. But monitoring covers what you have wired into it, and the expiries that bite hardest are usually the ones nobody thought to wire up: a vendor licence, a domain registration, an appliance certificate, a cloud commitment. The ambition of good observability practice for SRE and DevOps teams is wide, but it still starts from a list of things someone knows about. The calendar is where you write that list.
Treat monitoring checks as a second layer. The calendar says “this will end on this date and Priya owns it.” The alert says “it is ending soon and nobody has acted.” Together they close the gap from both sides.
Myth 3: “The vendor will email us”
They might. Renewal emails go to whoever signed up, often an engineer who has since left, or to a shared mailbox that sits in a folder nobody reads. Some vendors send one notice and no more. Others send notices to an address that was valid five years ago.
Copy the date from the vendor’s own dashboard into your calendar the day you buy. If the vendor later changes it, an email will probably arrive; update the entry then. The real defence is that your reminder does not depend on someone else’s mail.
Myth 4: “We’ll remember, it’s only a handful of things”
The handful grows. Today it is three certificates and a domain. A year from now it is three dozen certificates, six licences, two cloud commitments, four runtime end-of-support dates and the renewal of the support contract that nobody renegotiated. And the people who remember the first three leave, go on holiday or change teams.
Memory is a fine tool for things you use daily and a poor one for things that happen once a year. Anything annual should be written down. This is not a criticism of anyone’s diligence; it is a recognition of how human memory works.
Myth 5: “A key-dates calendar is just extra bureaucracy”
It sounds like paperwork until you count what it replaces. Without it, the team pays in out-of-hours pages, rushed purchase approvals and hurried upgrades that skip testing. With it, the cost is an afternoon to set up and a few minutes each quarter to review. The effort scales with the number of dates, not with the size of your organisation.
A good rule is to keep the calendar tiny in scope. Only external dates go in, meaning things set by someone you do not control. Sprint goals and internal milestones live in your project tools. That boundary keeps the calendar readable and stops it from becoming a dumping ground that people start to ignore.
Myth 6: “This is only about certificates”
Certificates are the famous case, but the pattern is broader. Consider support lifecycles: operating system versions and orchestrator releases move out of support on published dates, and security teams care about that. Consider licence terms and cloud commitments that end and revert to a more expensive rate. Consider API deprecations announced months in advance. For teams thinking about security embedded in delivery, the contrast explained in how DevSecOps differs from plain DevOps for leaders is a useful background: security work is full of scheduled obligations that benefit from exactly this kind of tracking.
There is a quieter version of this belief too: “someone else owns that.” In shared environments, a certificate on a load balancer might belong to the platform team, the application team or nobody. Ambiguity about ownership is itself a date-related risk, because the reminder fires and everyone assumes a neighbour will act. Writing a single named owner next to each date forces that conversation early, while it is still cheap.
What a lean calendar looks like instead
Put the myths aside and the working practice is modest.
- One shared calendar called something obvious, visible to the whole team.
- Every entry on the real deadline, with two reminders: one early enough to cover the slowest realistic renewal, one shortly before the cutoff.
- An owner and a deputy on each event, so a single absence cannot hide it.
- Titles that start with a verb, so the entry reads “Verify cert renewal ran” instead of a bare noun.
- A quarterly check of the next ninety days to catch moved dates and departed owners.
Dates in other fields
It helps to remember that this habit is not unique to infrastructure. Investors follow filing deadlines and results days, and the finance-education site Stocks Mantra has an important-dates part in its resources for exactly that audience. It is educational rather than advice, but it makes the same point from another corner: a fixed date is only dangerous if it sits unrecorded.
Where to start if you buy none of the myths
Pick the category that hurt you most recently and start there. If it was a certificate, list every certificate you can find and the expiry of each. If it was a licence, list your licences. Spend an hour, not a week. You will not catch everything on the first pass, and that is fine, because the quarterly review exists to catch what you missed.
Then run one test. Create a fake event for tomorrow and see who receives the reminder. It is surprising how often the person you thought would be notified is not. Fixing that is a ten-minute job today and a lifesaver in the autumn.
The takeaway
Every one of these myths is attractive for the same reason: each lets you skip a small, boring task by pointing at something that sounds more sophisticated. Automation, monitoring, vendors and memory are all useful, but none of them is a list of dates with names against them. The calendar is the only thing that is, and it takes less effort than the first postmortem you will write without it.