Skip to main content

Production checklist

PC = Production. MC = Mission Critical and Dedicated. A line marked for PC applies to MC as well.

Credentials​

CheckPlan
☐The delivered admin keys are deleted; your own are in a password manager held by both technical contactsPC
☐Each workload and environment has its own live key (or OAuth client), narrowest scopes, expiry at most 90 daysPC
☐Keys are read from a secret store at start; none is in code, images, CI logs or ticketsPC
☐Secret scanning has the key patternPC
☐An IP allow list on each production key, or private connectivity onlyMC
☐OAuth with private_key_jwt or mutual TLS, if your policy needs no long-lived secretMC

Client​

CheckPlan
☐Every write sends x-amz-content-sha256 and every POST an Idempotency-Key, the same on each retryPC
☐Retries: 429, 5xx and network errors, backoff with jitter, retry-after honoured; other 4xx never retried unchangedPC
☐Error handling branches on error_code, and tolerates unknown codes, fields and event typesPC
☐Each forming series' closed segments, right edge and edge stored in one write, one writer per series; carrying on after a restart testedPC
☐The jurisdiction endpoint is used, never a regional addressPC
☐traceparent sent; server-timing recordedPC
☐Profile versions pinned where results must reproducePC
☐gRPC connections reconnect on GOAWAY or reset and resend what was not answeredMC
☐Callers run in two regionsMC

Events​

CheckPlan
☐Signatures verified on the raw body; stale timestamps rejected; id deduplicatedPC
☐2xx returned within 10 seconds; work done from a queue with a dead-letter queuePC
☐Webhook secret rotation tested with both secrets livePC

Data​

CheckPlan
☐Series names are opaque; the mapping is in your store onlyPC
☐Segments stored by client prefix; deleting a client deletes its prefixPC
☐Jurisdiction matches where your data must stayPC
☐Customer-managed encryption key configured, if your policy needs oneMC

Capacity and proof​

CheckPlan
☐Peak bars a second and backfill volume within the plan, or extra capacity confirmedPC
☐Load and soak tests passed (playbook stage 8)PC
☐Failover rehearsal passedMC

Operations​

CheckPlan
☐Alerts on success rate, p99, 429 rate, edge and out-of-order errors, event lag and dead-letter depth, routed to on-callPC
☐On-call subscribed to status.patternode.comPC
☐Runbooks written and found by on-call (playbook stage 9)PC
☐Technical contacts can open Severity 1 by phoneMC
☐Blackout periods registeredMC
☐Exit plan writtenMC