build.allanninal.dev

Part 5 of 7 · Document expiry watcher series ~5 min read

How an item gets renewed

An alert lands in Maria’s Slack DM at 8:03am. The cyber-insurance policy expires in 60 days. There’s an Acknowledge button. What happens when she taps it? The honest answer is “it depends on what she actually did.” This post walks through the three things the watcher can do on an acknowledgment — renew, snooze, ack-only — and how the registry, the chain state, and the audit trail all stay in sync.

Key takeaways

  • Three actions per acknowledgment: ack-and-renew (new expiry, fresh chain), ack-and-snooze (delay), ack-only (silence the chain).
  • Each action updates the registry sheet via the Sheets API and writes an audit row.
  • A renewal archives the old chain to a separate sheet for history.
  • Snooze is bounded — you can only snooze a few times before the watcher escalates anyway.
  • The Acknowledge button is a Slack interactive message backed by a Function URL.

Three actions on Acknowledge

Three actions on the Acknowledge button A diagram showing one input on the left flowing through a small interactive Slack panel, then branching into three action paths. Far left: an "Alert in Slack DM" box showing a typical alert message — item name, days remaining, renewal cost, link to source — with three Slack-button placeholders below: Renew, Snooze, Ack only. The owner taps one button. The middle column shows the three branches. Branch one, Renew: opens a Slack modal with a date picker for the new expiry, an optional renewal-cost field for the new contract value, and a Save button. On save, a Function URL Lambda updates the registry sheet via the Sheets API with the new expiry and cost, archives the old item's chain history to a separate sheet, clears the chain state in the ew-pings DynamoDB table, and writes a renewed event to the audit trail. Branch two, Snooze: opens a smaller Slack modal asking how many days to snooze (default 7); on save, the Function URL Lambda writes a snooze row to the ew-ack table that suppresses pings for that item until the snooze ends. The chain itself isn't changed. Snooze can only be applied a limited number of times per chain (default three) before the next tick ignores it and pings anyway. Branch three, Ack only: silences the rest of the chain for this expiry; the watcher won't ping again until the next renewal cycle. Useful when the owner is handling it themselves and doesn't want further reminders. The right side shows the convergence: every action writes a row to the ew-audit DynamoDB table with timestamp, item id, action, by-user, and notes. A note at the bottom: Ack-only doesn't change the expiry — it just stops the noise. The watcher remembers and the next renewal cycle starts on schedule. Alert in Slack DM item, days, cost, link [Renew] [Snooze] [Ack only] Action 1 Renew • Modal: new expiry date, new renewal cost • Sheets API updates row • Old chain archived Action 2 Snooze • Modal: snooze N days (default 7) • ew-ack row suppresses pings until snooze ends Action 3 Ack only • Silence rest of chain for this expiry • No registry change — expiry stays same Audit trail DynamoDB ew-audit timestamp · item_id action · by-user notes Ack only doesn’t change the expiry — it stops the noise. The next renewal cycle starts on schedule.
Fig 5. Three actions per acknowledgment, three different effects. Renew updates the expiry and starts a fresh chain. Snooze delays without dismissing. Ack-only silences the chain without changing the expiry. Every action writes to the audit trail.

Action 1: ack-and-renew (the most common)

Maria worked with the broker, signed the new policy, and now needs to update the registry. She taps Renew. A small Slack modal opens with two fields: New expiry date (defaulting to one year from the previous expiry, which is right most of the time) and New renewal cost (defaulting to the previous cost). She edits whichever fields actually changed and hits Save.

The Save button submits to a Function URL Lambda. Three things happen, in order. First, the Sheets API updates the row in the registry sheet: new expiry_date, new renewal_cost, and a small note in the last_renewed column with today’s date and the user who acted. Second, the existing chain’s rows in ew-pings are copied to ew-pings-archive with a chain id, and the live chain is cleared. Third, an action: renewed row is written to ew-audit with the user, timestamp, old expiry, new expiry, and any cost change.

Tomorrow’s tick reads the registry, sees the new expiry date is more than 90 days out, and lands at healthy. The owner won’t hear from the watcher about this item again until the new chain’s first window crosses.

Action 2: ack-and-snooze (the deferral)

Some renewals take time the alert chain doesn’t plan for. The vendor is slow to respond. The legal review is stuck behind a holiday. The CEO is the only person who can sign and they’re traveling. Maria isn’t ready to renew, but she’s also handling it — she just needs the watcher to be quiet for a week.

Snooze opens a small modal asking for the number of days, with a 7-day default and a max of 14. On save, a row is written to ew-ack with (item_id, snooze_until). The next day’s tick reads that row in the “already acknowledged?” check from Part 3 and treats the item as healthy until the snooze ends. When the snooze ends, the watcher re-evaluates the chain from where it was — if the item is now in escalation territory, the next ping is an escalation.

Snooze is bounded. The rules doc has a configurable max_snoozes_per_chain setting (default three). After that many snoozes on the same expiry, further snooze attempts are rejected with a “You’ve hit the snooze cap on this item; please renew or escalate” reply, and the next tick pings normally regardless. This is a soft constraint that exists because the most dangerous failure mode is repeatedly snoozing an item to nowhere.

Action 3: ack-only (the “I’ve got it”)

Sometimes the owner doesn’t want to renew right now and doesn’t want to be reminded again either. Maybe the policy is genuinely not getting renewed (changing vendors). Maybe the item is being deprecated. Maybe the owner is going to handle it manually and doesn’t need the system in the loop.

Ack only writes a row to ew-ack with (item_id, ack_until: expiry_date) — effectively, “don’t ping me about this item again until its expiry passes.” The expiry itself isn’t changed. The chain is silenced for the rest of this cycle. If the item ends up actually getting renewed via Lane 1 (somebody just edits the registry sheet directly), the new expiry resets the chain naturally on the next tick.

If the expiry passes without a renewal, the watcher does one more thing: it writes the item to a separate lapsed sheet in the same Drive folder, with the date it lapsed and the last-known owner. The lapsed sheet is what the monthly summary in Part 6 reports on. A lapsed item that was ack-only’d gets a small note — “ack-only by Maria on 2026-04-15” — so the audit trail isn’t a mystery later.

Every action is logged, every action is reversible

The ew-audit table records every renew, snooze, and ack-only with the user who took the action, the timestamp, and a snapshot of the row before and after. If a wrong renewal date gets entered (off by a year, off by a day), a rep can run an “undo last action” through a small admin command that reads the previous-state snapshot and restores the row. The undo is itself an audit row, so the trail of edits stays clean.

This kind of reversibility matters most for the renewals you’ll only think about once a year. The next time the cyber-insurance comes up, it’ll be Maria again or it’ll be the person who took her job after she got promoted. Either way, the audit trail is the only memory the next person has.

Next post: the cost breakdown. The whole pipeline above runs in coffee-money territory at SMB volume; Part 6 explains exactly where the dollars go and why it’s less than the lead intake bot’s bill.

All posts