mh-cto-sdlc-hypercare

Hypercare

Hypercare is elevated, not paranoid. The first 24-72 hours post-launch are the highest-risk operational window because: traffic patterns are new, edge cases that testing missed are found by real users, and configuration surprises surface under real load. Elevated readiness means: shorter monitoring intervals, faster defect response, and lower severity threshold for action.

Elite character: Hypercare ends when stability is demonstrated — not when a timer expires. A product that is crashing on Day 3 is not out of hypercare just because it is Day 3.

Step 1 — Load Go-Live Context

Read _mh-output/cto/sdlc/go-live/{latest}_go-live-log.md.

Confirm: product launched (not rolled back). If rolled back: "Go-live was rolled back. Hypercare only applies to a live system. Resolve the rollback cause, re-run /mh-cto-sdlc-go-live, then begin hypercare."

Establish hypercare window:

• Standard: 48 hours from T+0
• Extended (use if): Any incident in first 24h, any rollback condition that was narrowly avoided, any P0 path not fully verified at gate

Step 2 — Monitoring Cadence

During hypercare, monitor at elevated frequency:

Window	Frequency	Metrics to Check
T+0 to T+4h	Every 30 minutes	Error rate, P95 latency, active users, anomalous logs
T+4h to T+24h	Every 2 hours	Same + memory growth, DB connection pool, queue depth
T+24h to T+48h	Every 4 hours	Same + performance regression check vs pre-launch baseline

For each monitoring check, record:

{timestamp} — Error rate: {N}% | P95: {N}ms | Users: {N} | Anomalies: {none / description}

Step 3 — Defect Triage Protocol

During hypercare, ALL defects are treated as P1 regardless of severity:

• A cosmetic bug discovered during hypercare gets the same immediate triage as a data bug
• Triage does not mean fix — it means classify, assess impact, and decide on response

For each defect found:

ID	Description	User Impact	Response	Status
D-001	{description}	{None / Degraded / Broken}	{Fix + deploy / Hotfix / Rollback / Monitor}	{Open / Resolved}

Response options:

• Fix + deploy: Low-risk change, CI/CD gate passes, deploy normally
• Hotfix: High-impact defect, expedited review, deploy outside normal cycle
• Rollback: User-impacting defect with no quick fix — rollback to previous version
• Monitor: Low user impact, no immediate fix, monitor for worsening

Step 4 — Hypercare Closure Criteria

Hypercare closes when ALL of the following are true:

• [ ] No P0/P1 defects open for more than 2 hours without a resolution plan
• [ ] Error rate has been within baseline for 12 consecutive hours
• [ ] P95 latency has been within baseline for 12 consecutive hours
• [ ] No new defect categories discovered in the last 24 hours
• [ ] No open rollback risk (no defect that, if it worsens, would require rollback)

If hypercare window expires (48h) but closure criteria are not met: extend hypercare and document the reason.

Step 5 — Write Hypercare Log

Save to _mh-output/cto/sdlc/hypercare/{YYYY-MM-DD}_{r###}_hypercare-log.md:

# Hypercare Log

**Product:** {name}
**Launch date:** {date}
**Hypercare window:** {start} to {end}
**Outcome:** STABLE — hypercare closed / EXTENDED — reason: {reason}

---

## Monitoring Log

{Timestamped entries from Step 2}

## Defects Discovered

{Table from Step 3 — or "None"}

## Closure Assessment

{Checklist from Step 4 with each item verified or flagged}

## Lessons for Phase 8

{Any patterns from defects or monitoring that should feed the Phase 8 retrospectives}

Step 6 — Present Summary

Hypercare: {CLOSED (stable) / EXTENDED}

Duration: {N} hours.

Defects found: {N} — {N} resolved, {N} open with mitigation.

Stability confirmed: Error rate and latency within baseline for {N}h.

Lessons for Phase 8: {N} items captured.

Next step: Run /mh-cto-sdlc-outcome-measure to begin Phase 8 Validation & Evolution.