CODE RESILIENCE

Every incident should make your code more resilient.

Traversal brings its Production World Model™ into development, so engineers and coding agents build with full production context, and risky changes get caught before they ship.

Book a Demo

Coding agents that know production.

Any coding agent connected through the Traversal MCP server can ask whether a change is safe to merge, and get an answer grounded in live production.

checkout-svc — claude — 104×38

✻ Welcome to Claude Code!
/help for help, /status for your current setup
cwd: ~/code/checkout-svc

MCP: traversal connected

> Investigate whether this diff breaks anything in production before I commit.

⏺ I'll ask Traversal to check this diff against production before you commit.

⏺ traversal - investigate (MCP)(question: "Does raising paymentsClient retries from 2 to 5 break anything in production?", diff: "src/payments/client.ts")

✻ Investigating production… (esc to interrupt)

⎿ session_id: sess_7f19c2 · status: complete · elapsed_seconds: 41

CAUTION A similar retry-limit change 6 weeks ago led to a connection-pool exhaustion incident on this service under peak load.

⏺ Traversal flags this as risky: the last time retries went up on this client, payments-db ran out of connections at peak. I'd hold the commit. Want me to see what it would take to make this safe?

? for shortcuts⧉ In checkout-svc

Risks a diff alone can't show.

Traversal surfaces the failure paths that only exist in production, like legacy callers relying on old behavior or a fleet-wide rollout scheduled the same week.

checkout-svc — claude — 104×38

✻ Welcome to Claude Code!
/help for help, /status for your current setup
cwd: ~/code/checkout-svc

MCP: traversal connected

⏺ Update(src/payments/client.ts)

⎿ Updated src/payments/client.ts with 1 addition and 1 removal

18export const paymentsClient = createClient({

19 baseUrl: env.PAYMENTS_URL,

20 timeoutMs: 5000,

21- retries: 2,

21+ retries: 5,

22});

> Investigate whether this diff breaks anything in production before I commit.

⏺ traversal - investigate (MCP)(question: "Does raising paymentsClient retries from 2 to 5 break anything in production?", diff: "src/payments/client.ts")

CAUTION A similar retry-limit change 6 weeks ago led to a connection-pool exhaustion incident on this service under peak load.

⏺ Traversal flags this as risky. I'd hold the commit. Want me to see what it would take to make this safe?

> why? it's a one-line change

⏺ traversal - get_findings (MCP)(session_id: "sess_7f19c2")

⎿ Failure paths that only exist in production:

▲ Legacy callers retry on top of you. mobile-bff v1, partner-api, and batch-reconciler each retry 3× on 5xx. With retries: 5, one failed order can hit payments-db 15 times.

▲ Fleet-wide rollout the same week. CHG-5120 (Thursday) lowers payments-db max connections from 400 to 300 across every region.

▲ It has happened before. INC-3874 (Aug 22): a retry bump on this client exhausted the payments-db pool at peak for 34 minutes.

⏺ None of this is visible in the diff itself. The risk is in who else calls payments-db and what's changing around it this week.

? for shortcuts⧉ In checkout-svc

Know what to do before you merge.

Every review ends with a clear sequence: what to fix first, what to watch, and when it's safe to ship.

checkout-svc — claude — 104×38

✻ Welcome to Claude Code!
/help for help, /status for your current setup
cwd: ~/code/checkout-svc

MCP: traversal connected

> Investigate whether this diff breaks anything in production before I commit.

⏺ traversal - investigate (MCP)(question: "Does raising paymentsClient retries from 2 to 5 break anything in production?", diff: "src/payments/client.ts")

CAUTION A similar retry-limit change 6 weeks ago led to a connection-pool exhaustion incident on this service under peak load.

⏺ Traversal flags this as risky. I'd hold the commit. Want me to see what it would take to make this safe?

> yes, make it safe to ship

⏺ traversal - recommend (MCP)(session_id: "sess_7f19c2")

⎿ Fix first

1. Cap retries at 3 with exponential backoff and jitter.

2. Send a retry budget header so legacy callers stop multiplying attempts.

⎿ Watch after deploy

· payments-db active connections (alert at 80% of the new 300 limit) · checkout p99

⎿ Safe to ship

· After CHG-5120 completes Thursday, behind flag checkout.retry_v2 at 10%

⏺ Following Traversal's plan. Applying steps 1 and 2 now.

⏺ Update(src/payments/client.ts)

⎿ Updated src/payments/client.ts with 3 additions and 1 removal

21- retries: 5,

21+ retries: 3,

22+ backoff: { type: "exponential", baseMs: 200, jitter: true },

23+ retryBudget: { header: "x-retry-budget", max: 3 },

⏺ traversal - investigate (MCP)(question: "Re-check the updated diff", session_id: "sess_7f19c2")

✻ Re-checking against production… (esc to interrupt)

SAFE TO MERGE Worst case drops to 3 attempts per order. Ship behind checkout.retry_v2 at 10% after Thursday.

? for shortcuts⧉ In checkout-svc

Every incident makes the next change better.

Every incident, investigation, and review feeds back into the Production World Model™, so each new change is checked against everything Traversal has learned.

inventory-sync — claude — 104×38

✻ Welcome to Claude Code!
/help for help, /status for your current setup
cwd: ~/code/inventory-sync

MCP: traversal connected

> bump inventory-sync client retries to 4, then check with traversal

⏺ Update(src/clients/warehouse.ts)

12- retries: 1,

12+ retries: 4,

⏺ traversal - investigate (MCP)(question: "Is raising warehouse client retries from 1 to 4 safe?")

✻ Investigating production… (esc to interrupt)

⎿ Checked against 48 past incidents, 212 investigations, and 36 change reviews

CAUTION Same retry-amplification pattern Traversal learned from last week's checkout-svc review: warehouse-api is also called by 2 legacy services that retry on their own.

Recommended: cap at 3 with backoff and a retry budget header, the fix that cleared checkout-svc.

⏺ Traversal caught this from what it learned last week, before anyone had to repeat that incident. Applying the same pattern now.

? for shortcuts⧉ In checkout-svc

CUSTOMER PROOF

21%

Fewer incidents across the organization

At DigitalOcean, production context in development led to more resilient code, resulting in 21% fewer incidents across the organization.

Customer Story

Coding agents that know production.

Risks a diff alone can't show.

Know what to do before you merge.

Every incident makes the next change better.

Ready to put AI to work?