I had 30 Stripe webhook timeouts in three days and no idea why
I run a small dev shop in Austin—two contractors, me, and a handful of Shopify merchants who need custom checkout flows. One client sells hand-poured candles and wanted a subscription upsell at checkout. We built it with Stripe Checkout and a webhook handler that creates the subscription record in their Rails app when the payment succeeds. It worked fine in staging. Went live on a Thursday. By Saturday morning I had 30 failed webhook attempts in the Stripe dashboard, all timing out after five seconds.
Stripe retries failed webhooks with exponential backoff, so by the time I woke up Sunday the client had three customers who'd paid but didn't get their subscription access. I refunded two of them manually and spent the rest of the weekend trying to figure out what was wrong. The logs showed the webhook handler was receiving the payment_intent.succeeded event, querying the database, then... nothing. No error, no crash, just a timeout.
I tried Claude Sonnet 4.5 first for a code review, then switched to o1 when Claude didn't catch the root cause. It took three attempts and about $8 in API costs before o1 spotted the race condition. Here's what each model found, what I missed, and the two-line fix that stopped the timeouts.
First attempt: Claude Sonnet 4.5 caught the N+1 query but missed the timing issue
I pasted the webhook controller code into Claude and asked it to review for performance issues. The handler was about 80 lines: verify the webhook signature, parse the event, find the customer record by Stripe ID, create a subscription, send a confirmation email. Claude came back in four seconds with three suggestions.
One was an N+1 query I'd introduced when I added eager loading for the customer's order history. Fair—I'd written customer.orders.each without an includes(:line_items) and it was firing 20 extra queries for customers with large order histories. Claude suggested adding .includes(:line_items, :discounts) and showed me the exact line. I made the change, deployed, and waited.
The timeouts kept happening. Not every webhook, maybe one in five, but enough that Stripe was still retrying and customers were still emailing. Claude had found a real performance issue but it wasn't the one causing timeouts. I needed something that could reason through the async flow, not just review the code line by line.
Second attempt: o1 preview asked about the payment intent lifecycle and I realised I didn't know
I switched to o1 because I'd read it was better at multi-step reasoning. I gave it the same controller code plus the Stripe event payload from one of the failed webhooks. Instead of a code review, o1 asked three questions: when does Stripe fire payment_intent.succeeded, what happens if the webhook arrives before the checkout session is marked complete in my database, and am I locking the customer record during the subscription creation.
I didn't have good answers. I knew Stripe fires the event when the payment clears, but I'd assumed the checkout session webhook (checkout.session.completed) always arrived first. It doesn't. If the payment processor is fast, payment_intent.succeeded can arrive a few hundred milliseconds before the session webhook, and my handler was querying for a checkout session record that didn't exist yet. The query would hang waiting for a row lock, hit Stripe's five-second timeout, and fail.
o1 didn't give me the fix yet—it just pointed out the race condition. But that was enough. I added a sleep(2) at the top of the handler, deployed, and watched. The timeouts stopped for about six hours, then came back. Sleeping for two seconds worked most of the time but not always. I needed a real fix, not a delay.
Third attempt: o1 reasoning mode walked through the retry logic and suggested idempotency keys
I went back to o1 and asked it to reason through the full flow: checkout session created, payment succeeds, two webhooks fire in unpredictable order, handler needs to create exactly one subscription. I used the reasoning mode (the one that shows its thinking step by step) because I wanted to see how it was piecing together the solution.
It took about 15 seconds and gave me a three-part answer. First, use Stripe's idempotency keys to make the subscription creation safe to retry. Second, check if the subscription already exists before creating it. Third, wrap the whole handler in a database transaction with a row lock on the customer record so two webhooks can't create duplicate subscriptions.
The idempotency key part was new to me. Stripe lets you pass an Idempotency-Key header with any API request, and if you retry the same request with the same key, Stripe returns the original result instead of creating a duplicate. I was already using webhook event IDs as idempotency keys in the database (so I wouldn't process the same event twice), but I wasn't passing them to Stripe when I created the subscription.
I added idempotency_key: event.id to the subscription creation call and wrapped the handler in ActiveRecord::Base.transaction. Deployed. No more timeouts. I've processed about 200 webhooks since then with zero failures.
What Claude caught versus what o1 caught and why it matters for debugging
Claude found the N+1 query in four seconds. It's fast, it's good at surface-level code review, and it would've been enough if my problem had been a slow query. But it didn't ask about the async flow or the order of events. It reviewed the code I gave it and stopped there.
o1 took longer—15 seconds for the reasoning pass—but it asked better questions. It wanted to know about the Stripe event lifecycle, the database schema, and what happens when two webhooks arrive out of order. That's what reasoning models are for: multi-step problems where the bug isn't in one function, it's in how three systems interact.
If I'd started with o1 I would've saved about six hours and one very annoyed client. But o1 costs more per request (about $0.15 for the reasoning pass versus $0.02 for Claude's review), so I don't route everything to it. I use Claude for code review and style checks, o1 for debugging and architecture decisions. If you're billing clients by the hour, knowing which model to use for which task is worth the time to figure out.
The two-line fix and what I'd do differently next time
The fix was adding an idempotency key and a transaction lock. In Rails it looks like this:
ActiveRecord::Base.transaction do
customer = Customer.lock.find_by(stripe_id: event.data.object.customer)
return if customer.subscriptions.exists?(stripe_payment_intent_id: event.data.object.id)
Stripe::Subscription.create({
customer: customer.stripe_id,
items: [{ price: price_id }],
idempotency_key: event.id
})
end
The lock prevents two webhooks from creating duplicate subscriptions. The exists? check skips the creation if we've already processed this payment intent. The idempotency_key makes the Stripe API call safe to retry. Two lines of actual code, but it took three debugging sessions and two models to get there.
Next time I'll start with o1 for anything involving async events or third-party APIs. Claude's great for reviewing a single function, but if the bug is in the timing or the interaction between systems, you need a model that can reason through the whole flow. I keep both in Kryotta's workspace so I can switch without opening a new tab or copying prompts between tools.
Questions people ask
How much did the debugging cost in API calls?
About $8 total. Claude's three code reviews were maybe $0.10 combined, o1's reasoning passes were $0.15 each, and I ran a few throwaway prompts testing different fixes. If I'd hired someone to debug it I would've paid $150 minimum.
Can you use DeepSeek R1 instead of o1 for reasoning?
Probably. I haven't tested R1 on webhook debugging yet, but it's a reasoning model and it costs about one-fifth as much as o1. If you're doing this kind of work regularly, R1 is worth trying first and upgrading to o1 if you need the extra accuracy.
Do you always use idempotency keys for Stripe webhooks?
I do now. Stripe recommends it in their docs but I'd skipped it because my handlers were simple. The race condition taught me that "simple" doesn't mean "safe"—if two events can arrive in any order, you need idempotency.
Which model is better for Stripe integration work overall?
Claude for writing the initial integration and reviewing code. o1 for debugging production issues and reasoning through edge cases. I wouldn't use o1 to generate boilerplate, and I wouldn't use Claude to debug a race condition. Route the task to the model that's built for it.
If you're debugging your own webhook timeouts or trying to figure out which AI model to use for code review, try Kryotta—you can switch between Claude, o1, DeepSeek R1, and six other models in one workspace without juggling API keys or subscriptions.
