Start Building

Lesson 44: Post-Closure Recurrence Watch and Reopen Lifecycle for RPG Live-Ops

Lesson 43 closed the loop with attestation and remediation proof. Reality still sends you repeat signals after closure: the same crash signature, the same refund spike pattern, or the same vendor latency class.

This lesson adds a recurrence watch so those signals either reopen a controlled lineage or spawn a new incident without orphaning metrics.

Pixel scene illustration for post-closure recurrence watch lesson

What you will build

By the end of this lesson, you will have:

  1. A recurrence_watch_register.csv tying closed incidents to watch windows and owners
  2. A reopen versus new incident decision tree with explicit packet inheritance rules
  3. Dashboard continuity fields so charts do not pretend a reopen is a brand-new universe
  4. Launch control counters that surface open watches without silently clearing closure credit

Step 1 - Define the watch window after closure

Pick a default window such as 30 or 90 days per incident class. During the window:

  • telemetry alerts carry parent_incident_id metadata
  • support macros include the same id in internal-only fields
  • executive dashboards show a thin recurrence band under the original closure marker

If your game cadence is faster, shorten the window for hotfix-class incidents only.

Step 2 - Author recurrence_watch_register.csv

Minimum columns:

column purpose
watch_id stable id (WATCH-2026-0418-01)
parent_incident_id closed incident reference
closure_packet_version last approved closure packet id
watch_start_utc / watch_end_utc window bounds
signal_types crash signature bucket, refund spike, vendor latency, and so on
owner who reads weekly watch summaries
status active, cleared, escalated_reopen, spawned_new

Pro tip: If you already run a weekly risk review, attach watch status as a single appendix row so the ritual stays lightweight.

Step 3 - Reopen versus new incident decision tree

Use reopen when:

  • root cause class matches the prior incident taxonomy
  • affected systems overlap materially with the prior scope
  • legal or regulator context expects continuous narrative across filings

Use new incident plus link-back when:

  • root cause is different even if symptoms look similar
  • contracts or insurance buckets require a fresh clock
  • prior closure included explicit waiver language that a reopen would contradict

In both cases, copy forward parent_incident_id into a lineage_ids field on the new row so analytics never loses the thread.

Step 4 - Wire dashboards without rewriting history

Add dashboard rules:

  • reopened incidents display as a branch off the original closure marker, not a flat new spike
  • week-over-week charts annotate reopen_of=INC-... in tooltips or subtitles
  • yellow thresholds reference post-closure baseline not global lifetime baseline

If you also ship content on tight cycles, keep cadence discipline aligned with Are Patch-Every-Friday Rituals Slowing Small Teams Down - A Contrarian Scheduling Take for 2026 so watch windows are not drowned by unrelated noise.

Step 5 - Launch control integration

Extend launch packet fields:

  • active_recurrence_watch_count
  • highest_watch_escalation_state (none, yellow, red)
  • next_watch_review_utc

Promotion guidance:

  • red means at least one watch escalated to reopen review without a written decision
  • yellow means a watch is inside seven days of expiry with open signals

Common mistakes

Mistake: Treating every similar crash as a reopen

Fix: require taxonomy match, not only stack trace string match.

Mistake: Clearing watches when marketing wants charts green

Fix: cleared requires owner sign-off plus zero matching signals for one full review cycle.

Mistake: Hiding watches from player-facing status pages

Fix: watches are internal. Player pages still follow Lesson 42 comms rules.

Pro tips

  • Add one calendar burn-down per watch so expiry is visible.
  • Snapshot dashboard configs when closure happens so baseline comparisons stay honest.
  • Pair vendor-heavy watches with Lesson 39 subprocessor alerts when the same vendor id reappears.

Mini challenge

  1. Create one recurrence_watch_register.csv row for a fictional closed incident with a 45-day window.
  2. Write two bullet decisions: one reopen case and one new plus link-back case.
  3. Add mock dashboard tooltip text that includes reopen_of.

FAQ

Do watches replace on-call paging?

No. Watches are slow evidence. Paging stays for acute incidents.

What if signals are noisy during a live event?

Extend the window with a documented reason or split signal types so festival traffic does not false-positive vendor latency watches.

How does this interact with DSAR closure from Lesson 38?

If the parent incident touched DSAR work, the watch row should reference whether residual obligations still exist after closure. Legal should review cleared transitions.

Lesson recap

You now have a post-closure lifecycle that respects closure credit while still catching honest recurrence. Lineage ids, watch windows, and dashboard continuity keep audits and retros honest.

Next lesson teaser

Continue with Lesson 45: Cross-Incident Trend Rollup and Leadership Recurrence Heatmap for RPG Live-Ops to aggregate watch-level recurrence into class-level weekly risk signals.

Related learning