Alerting models: how often you hear about it

Updated August 21, 2026

Every team runs at its own pace. A small team that can rotate a secret between stand-up and lunch wants to hear about it differently from a platform group where the same change needs a ticket, a review, and a release window. That's what an alerting model is: the rule deciding which days produce an alert, so the reminders keep up with how you actually work.

The scenario

Every timeline below shows the same 30 days and the same credential:

• Today is May 1. The credential expires on May 15.
• The expiring threshold is 10 days, so the credential counts as expiring from May 5.
• Nobody rotates it. It lapses on May 15 and stays expired for the rest of the month — the pessimistic case, which is the one worth comparing.

Countdown

Alerts start three working days before expiry, then arrive every day through the day it lapses.

6 alerts over the 30 days — every day from May 10 to May 15.

The run-up is short and business-day aware. The window opens three working days before expiry, which is why it starts on May 10 here rather than the 12th — the weekend of the 13th and 14th doesn't count toward the three. From there an alert lands every day, weekends included, through the day the credential lapses.

This is a good fit for small, fast-moving teams, where rotating a secret is a short job someone can pick up the same afternoon. It's what the Free plan does, and for a lot of teams it's all they need. If a rotation in your organisation needs a change request and a release slot, widen the threshold and give yourself more runway with one of the models below.

Until resolved

An alert every day from the moment it enters the threshold until someone rotates it.

26 alerts over the 30 days — every day from May 5 to May 30.

Nothing gets forgotten here — the alert keeps arriving, weekends included, until somebody actually rotates the credential. That persistence is the point, and it's also the risk: twenty-six alerts about one credential is how a team learns to filter the sender into a folder. Pair it with untracking credentials you won't rotate.

Status transition

An alert only when the credential's status changes.

3 alerts over the 30 days — May 5, May 14, and May 15.

Three alerts, each one meaning something different: it entered the threshold, it expires tomorrow, it has expired. Quiet in between, so an alert arriving is itself information. The trade-off is that a missed alert is genuinely missed — there's no repetition to catch someone who was on holiday on May 5.

Side by side

Choosing one

The right model depends on how long a rotation takes in your organisation, and on whether an alert already has an owner. Countdown is the least intrusive of the three and the right default when rotations are quick and the team is small. A wide threshold with until resolved is the safe default when credentials are genuinely load-bearing and rotation is slow — provided you've untracked everything you don't intend to rotate, so the repetition only ever lands on real work. Status transition suits teams that route alerts somewhere durable, like an Azure DevOps work item, where the alert doesn't need to repeat because the ticket persists on its own.

Whichever you pick, the threshold matters more than the cadence: no model can warn you earlier than the window you gave it. See how monitoring works for setting that, and choosing your alert channels for where the alerts land.