Writing things down
Reminders
One-time or repeating prompts for dated work, with priorities, snoozing, completion, and dismissal.
“remind me to rotate the signing key before it expires in August”
A reminder that surfaces as the date approaches.
“what's coming up?”
Active reminders, soonest first.
“that's done”
Cleared.
What they're for
The things with a date attached that nothing else will catch: a certificate expiring, an API key rotation, a deprecation deadline, a contract renewal.
They surface in your sessions as the date nears — including the overdue ones, which is the case that matters.
Use a priority—low, normal, high, or urgent—to distinguish “worth remembering” from “an expired credential will break production.” Priority does not replace a realistic reminder date.
One-time and repeating reminders
A reminder can fire once or repeat daily, weekly, or monthly. Repeating reminders fit maintenance and review habits:
- check the backup restore report every week;
- review open launch risks every Monday;
- rotate a short-lived test credential each month.
Use a scheduled automation outside ContextStream when the work itself must run without a person. A reminder asks someone to act; it does not execute the rotation or deployment.
Reminders versus todos versus tickets
| Record | Use it for |
|---|---|
| Reminder | Something with a date that must not slip |
| Todo | Something to do, no date |
| Ticket | Work someone will pick up, with a lifecycle |
A certificate expiry is a reminder. "Clean up the config flag" is a todo. "The retry logic is wrong" is a ticket.
Where to put the detail
In the reminder itself. Six months on, "rotate the signing key" is not enough — which key, where does the current one live, what breaks if it lapses, what's the procedure. Write that down when you create it, while you know.
If the procedure is long, put it in a runbook and point the reminder at it.
A reminder that leaves time to act
A production signing key expires on August 31. Do not make August 31 the only reminder. If the rotation needs a two-week compatibility window and a review, set the reminder for early August and include:
- which signer and environments are affected;
- the expiry date and the date work must begin;
- the rotation runbook;
- the owner or ticket that will carry the work;
- the verification required before the old key is revoked.
When it surfaces, the assistant can open the procedure and active work instead of asking which key you meant. Completing the reminder means this rotation was handled. If the procedure must be reviewed every month, use a separate repeating reminder rather than pretending the key itself expires monthly.
A weekly “check the latest backup restore result” reminder is another good fit. It prompts a person to inspect evidence and escalate a failure; it does not run the restore test or certify the backup automatically.
Reviewing
Ask "what reminders do I have?" for the complete list or "what's coming up?" for active reminders in date order.
After it surfaces:
- Snooze it to a specific later time when the work is still required.
- Complete it when the obligation was satisfied.
- Dismiss it when it no longer applies.
Snoozing is not completion. Dismissing a repeating reminder should be a deliberate choice, because it may be the only prompt for the next occurrence.
If it doesn't work
It surfaced too late. Reminders surface as the date approaches. For long lead times, set the date to when you need to start, not when the thing expires.
It keeps surfacing after I did it. It needs closing. "That's done" clears it.
A teammate didn't see it. A reminder follows its creator and current scope; it is not an assignment workflow. For something another person must own, create a ticket or handoff and link the reminder or runbook.
A repeating reminder comes back after I handled this occurrence. Complete the occurrence without dismissing the series. If the recurring obligation is gone, dismiss it.