Quiet bootstrap: the day-one experience of a notification product

Half the appeal of a notification product is the moment it tells you the thing you'd otherwise have missed. The first time it lands in your Slack channel and says "ticket SR-145003 just came in, your on-call shift starts in 12 minutes," you trust it a little. The fifth time, you depend on it.

The other half of the appeal is what it does before that first useful message. Which is: nothing.

What a fresh install looks like by default

I'm building a small bridge that polls ConnectWise tickets and posts them to Slack. The naive cron tick is:

1. Poll CW for tickets updated since the last cursor.
2. For each ticket, compare against a snapshot map we keep on disk.
3. Anything we haven't seen before is NEW. Anything whose status changed is STATUS_CHANGED. Send each event to Slack.
4. Persist the new snapshot map and cursor.

This works exactly right on tick 2. On tick 1 it's a disaster.

Tick 1 has an empty snapshot map. Every open ticket in the tenant's CW is "something we haven't seen before." Every single one is classified NEW. The first cron run posts 200 messages to the team's Slack channel in a 10-second burst.

The team mutes the channel. Nobody re-enables it.

The fix is one branch in tick()

if self.quiet_bootstrap and not prior:
    # First-ever tick: snapshot every polled ticket as known,
    # advance the cursor, send nothing.
    self.state.save_snapshots({s.id: s for s in snapshots})
    self.state.save_cursor(new_cursor)
    result.bootstrapped = True
    return result

That's the entire delta. The bridge silently learns the state of the tenant on tick 1, and tick 2 fires only for the things that actually changed in the minute between them.

Why this isn't an option, it's the default

Some notification products surface "do you want the bootstrap flood?" as a config knob. That's the wrong default. The reason is that the team doing the install isn't the team that lives in the channel. The MSP owner sets up the bridge on Wednesday at 4 PM, the on-call rotation hits the channel at 11 PM, and the people who get the 200-message wall don't know who to ask to make it stop.

The right default is the one that doesn't degrade the channel's trust on first contact. The opt-out exists (someone wiping state to force a full resync needs the flood path), but it's a config flag, not a question on first run.

Generalizes

Any product whose value is "tell me when a thing happens" has this shape. Email digesters that read your existing inbox on day one. Status-page bridges that import current statuses. Webhook fan-out systems that start with a populated upstream. Each one needs a "silent learn what's already here" mode that runs once and never runs again.

The shape of the fix is the same: detect the empty-state condition, snapshot without firing, return a result that says you bootstrapped so the operator log can explain the zero-send tick. Two dozen lines including the test.

Build the silent-snapshot path before you build the alerting path. Otherwise the alerting path is the first impression of the product, and the first impression is "this is too loud."