Why the alert ladder is five rungs

Expiry monitoring looks like the easiest problem in the category. A certificate has a date on it. So does a domain registration — though a domain's real deadline is later and stranger than the one printed on it, which is what grace and redemption periods are. Compare the date to today. Send an email.

The hard part is not knowing the date. It is deciding how many times to say so.

Both obvious answers are wrong

Alert once. Send one email thirty days out. It arrives while the person who can act on it is on holiday, or in a week where they triage by deleting, and nothing happens. Thirty days later the certificate expires and the first anyone knows is a browser warning.

Alert daily. Send one every day until it is fixed. This works for about four days, after which the recipient creates a filter, and the filter also catches the one about the domain that actually lapses.

The failure modes are opposite and equally fatal. One is missed; the other is muted, which is being missed with extra steps.

Five rungs: 30, 14, 7, 3, 1

What we settled on fires exactly once at each of thirty, fourteen, seven, three and one days out. Five emails across a month, each at a moment that means something different:

• 30 days — file it. Nothing is urgent; you now know it exists.
• 14 days — schedule it. Enough time to raise a ticket and have it sit in a sprint.
• 7 days — this week. If it needs somebody else's approval, ask now.
• 3 days — today or tomorrow. Beyond this, a weekend can eat your margin.
• 1 day — now.

The spacing is not arithmetic and that is deliberate. The gaps compress as the deadline approaches because the appropriate response changes, and a reminder that says the same thing at the same interval trains you to ignore it. Five messages that each mean something different are read. Thirty identical ones are filtered.

Fires once, and only once

Each rung fires exactly once per condition. Uniqueness is enforced in the database on (monitor, condition, rung), not in application logic, because application logic that de-duplicates alerts is application logic that will eventually send two.

Cross a rung, get one email. Nothing repeats. The same ladder carries certificate expiry, domain expiry, and the surface changes we read out of the CT logs.

Resolution is automatic and silent-ish

When the certificate renews, the open alerts resolve themselves and you get one message saying so. Not five. The resolution is worth one email because "I fixed it" and "it is confirmed fixed" are different states and the second one is the useful one.

What we deliberately do not do is congratulate you at every rung you no longer qualify for.

The rung is in the alert

Every alert carries which rung fired. That sounds like an implementation detail and it is the thing that makes the emails readable: "7 days" and "1 day" are visibly different messages about the same certificate, and a person scanning an inbox can tell them apart without opening either.

It is also what lets us tell you, in a monthly report, that the earliest warning you got was thirty days before a deadline. "We caught it a month out" is the entire product in one sentence, and it is only sayable because the rung was recorded at the time.