RPReleasePilot

SaaS Billing

Billing Seat Sync Patch

Changes how subscription user counts sync between Stripe and internal records.

needs approval

Risk assessment

What this is: A weighted score from release attributes (blast radius, migrations, auth/billing touchpoints). Higher means more review before deploy.

critical
Risk score100/ 100

Halt deploy: resolve blockers, complete rollback verification, and obtain explicit approvals.

  • Production deployment+18
  • Database migration included+16
  • Billing/subscription logic affected+20
  • Multiple modules affected (3)+9
  • Rollback only partially verified+14
  • Unresolved checklist items (2)+16
  • Previous incident history on related surface+10
  • Medium test coverage signal+5
  • High blast radius+12
  • Pending or missing approvals+6

Context

Environment
production
Migration
Yes
Rollback
partial

Checklist

Required checks: Gates that must be green before you can queue this release in the simulator.

  • Finance sign-offRequired

  • Rollback rehearsal in stagingRequired

  • Webhook replay runbook reviewedRequired

Approvals

  • Taylor Ng (Engineering Lead)Pending

Affected modules

  • Stripe Sync
  • Subscription Seats
  • Webhooks

Rollback plan

Partial: revert app + run compensating seat reconciliation; migration rollback reviewed but not fully rehearsed in prod.

  1. Freeze seat mutation webhooks
  2. Redeploy prior billing worker
  3. Replay webhooks from checkpoint

Deployment simulation

Deterministic state machine — advances only when you click. Nothing provisions or deploys in the real world.

Current state: The timeline below reflects this run. After a rollback completes, use status updates and postmortem to document what happened.

Cannot queue yet. Release needs approval before deployment.

Pipeline overview

Pipeline phases (simulator). Current phase highlighted.

  1. Queued
  2. Preflight
  3. Deploying
  4. Verifying
  5. Monitoring
  6. Spike
  7. Rollback rec.
  8. Rolling back
  9. Restored
Current stateidle

Step detail

  1. Queue releasepending
  2. Verify approvalspending
  3. Check rollback planpending
  4. Run testspending
  5. Apply migration (if applicable)pending
  6. Deploy buildpending
  7. Verify health checkspending
  8. Monitor error ratepending
  9. Complete or escalatepending

Verification checks

Synthetic signals: Mock pass / warn / fail used to drive the story (e.g. error-rate spike). Not connected to live monitoring.

    Related incidents

    SEV-3monitoring

    Delayed Stripe Webhook Processing

    Service Billing Worker

    Webhook queue latency exceeded SLO.

    Related release →

    Status updates

    Template-generated — internal, customer-facing, and executive variants from current release context.

    What this does: Fills three comms drafts you can copy — useful after rollback or during an incident.

    No status update generated yet. Use "Generate status update" after an incident or deployment event.

    Audit trail (this session)