Is Stripe Down? How to Check Stripe Status Right Now

Statusfield Team
8 min read

Stripe payments failing? Learn how to check if Stripe is down, what error codes mean during an outage, how to protect revenue with graceful degradation, and how to get instant alerts before your customers notice.

Stripe processes hundreds of billions of dollars annually. When it goes down, the impact isn't just technical — it's a direct hit to revenue. Checkout flows fail, subscriptions don't renew, and every failed payment is a customer who might not come back. Understanding Stripe's status in real time, and building resilience into your integration, is essential for any business that takes payments seriously.

Here's how to diagnose a Stripe outage, understand what the errors actually mean, and protect your revenue when Stripe has issues.

Is Stripe Down Right Now?

Check these sources in order:

  1. Statusfield — Stripe status — real-time monitoring, updated continuously.
  2. Stripe's official status pagestatus.stripe.com shows component-level status across all regions and products.
  3. Twitter/X — search Stripe down or Stripe payments failing sorted by Latest.
  4. Stripe's developer Discorddiscord.gg/stripe where the community often surfaces issues quickly.

What Breaks During a Stripe Outage

Stripe's infrastructure is modular — different components can fail independently. Knowing which one is affected tells you whether checkout is broken, whether webhooks are delayed, or whether your dashboard data is just stale.

ComponentWhat it handlesImpact when down
APIAll Stripe API endpointsCharges, customers, subscriptions — all API calls fail
CheckoutStripe-hosted checkout pagesHosted checkout flows break for customers
Payment Intents3DS / SCA payment flowModern payment flows fail; checkout may not complete
WebhooksEvent delivery to your endpointsPayment confirmations delayed or not delivered
DashboardWeb interface for merchantsMerchants can't manage payments but API may still work
Billing / SubscriptionsRecurring billing engineSubscription renewals may fail or be delayed
ConnectMulti-party payments, marketplace flowsPayouts to connected accounts affected
RadarFraud detectionPayments may be blocked more aggressively or Radar rules not applying
Stripe.jsClient-side JavaScript libraryPayment form won't load or tokenize cards

Critical insight: Stripe separates Webhooks from the core API deliberately. During partial incidents, you may see API calls succeed but webhook delivery be delayed by hours. Never rely solely on webhooks to confirm payment success — always confirm via the API.

Stripe Error Codes During an Outage

Stripe's error system is detailed. Here's how to distinguish an outage error from a normal decline or integration error:

HTTP-level errors (infrastructure problems)

HTTP StatusMeaningIs it Stripe's fault?
500 Internal Server ErrorStripe backend errorYes — Stripe issue
502 Bad GatewayGateway/proxy errorYes — check status page
503 Service UnavailableStripe is overloaded or maintenanceYes — check status page
504 Gateway TimeoutStripe request timed outYes — often during incidents

Stripe error codes (application-level)

Stripe Error CodeMeaningOutage-related?
api_connection_errorCan't reach Stripe's APIPossibly — check network and Stripe status
api_errorSomething went wrong on Stripe's endYes — Stripe-side issue
rate_limit_errorToo many requestsNo — your integration is sending too fast
card_declinedCard issuer declined the chargeNo — not Stripe's fault
do_not_honorCard issuer declineNo — card issuer issue
insufficient_fundsCustomer has no fundsNo — customer issue
card_errorVarious card-level errorsNo — card/customer issue

The key distinction: api_error and HTTP 5xx errors are Stripe's infrastructure failing. card_declined, insufficient_funds, and other card_error subtypes are normal decline logic — they're not outages, even during high-volume periods.

The Real Business Impact of a Stripe Outage

Stripe outages are rare but consequential. Consider what actually happens:

Lost checkout completions. A customer reaching payment is highly intent-to-buy. An error at checkout — especially one with a generic "payment failed" message — creates doubt and often results in abandonment, even after Stripe recovers.

Subscription renewal failures. Stripe retries failed subscription charges automatically (Smart Retries), but during an outage, a charge that would have succeeded may be marked as failed and trigger a retry cycle. Customers may see incorrect "payment failed" emails.

Delayed webhook delivery. If your fulfillment system relies on payment_intent.succeeded webhooks, a webhook outage means orders are accepted but not fulfilled. You need reconciliation logic to handle this.

Double charges. Without proper idempotency key usage, a timeout during an outage may cause your system to retry a charge that actually succeeded on Stripe's end. This results in duplicate charges.

Building Stripe-Resilient Integrations

Use Idempotency Keys — Always

This is the single most important thing you can do. Idempotency keys allow you to safely retry a request without risk of creating duplicate charges.

const charge = await stripe.paymentIntents.create({
  amount: 2000,
  currency: 'usd',
  payment_method: paymentMethodId,
  confirm: true,
}, {
  idempotencyKey: `order_${orderId}_${userId}`, // unique, stable key per transaction attempt
});

If the first request times out and you don't know if it succeeded, retry with the same idempotency key. Stripe will return the original result rather than creating a new charge.

Implement Retries with Exponential Backoff

For api_error and HTTP 5xx responses, retry with backoff. For card_declined and other card errors, do not retry — they will continue to fail.

import stripe
import time
 
def create_payment_intent_with_retry(amount, currency, payment_method, order_id, retries=3):
    idempotency_key = f"pi_{order_id}"
    
    for attempt in range(retries):
        try:
            return stripe.PaymentIntent.create(
                amount=amount,
                currency=currency,
                payment_method=payment_method,
                confirm=True,
                idempotency_key=idempotency_key
            )
        except stripe.error.APIError as e:
            # Stripe server-side error — safe to retry
            if attempt == retries - 1:
                raise
            time.sleep(2 ** attempt)  # 1s, 2s, 4s
        except stripe.error.Timeout as e:
            # Request timed out — safe to retry with same idempotency key
            if attempt == retries - 1:
                raise
            time.sleep(2 ** attempt)
        except stripe.error.CardError as e:
            # Card declined — do NOT retry, surface error to user
            raise

Handle Webhook Delivery Delays

Stripe retries webhooks for up to 3 days when your endpoint is unavailable. But what if your endpoint is up and Stripe's webhook delivery is delayed?

Build reconciliation into your system:

// Don't rely solely on webhooks for critical state changes.
// Periodically query Stripe to reconcile:
async function reconcileRecentPayments() {
  const paymentIntents = await stripe.paymentIntents.list({
    created: { gte: Math.floor(Date.now() / 1000) - 3600 }, // last hour
    limit: 100,
  });
 
  for (const pi of paymentIntents.data) {
    if (pi.status === 'succeeded') {
      await fulfillOrderIfNotFulfilled(pi.metadata.order_id);
    }
  }
}

Graceful Degradation for Checkout

When Stripe is unavailable, don't just show a generic error. Give customers confidence and a path forward:

try {
  const result = await stripe.confirmPayment({ elements, confirmParams });
  if (result.error) {
    // Card error — show specific message
    showCardError(result.error.message);
  }
} catch (networkError) {
  // Stripe.js couldn't reach Stripe — likely an infrastructure issue
  showMessage(
    "We're having trouble processing payments right now. " +
    "Your card has not been charged. Please try again in a few minutes, " +
    "or contact support if this persists."
  );
  logError('stripe_checkout_network_error', networkError);
}

Set Up a Status Check Endpoint

Expose a health check in your app that verifies Stripe connectivity. Include it in your monitoring dashboard:

app.get('/health/stripe', async (req, res) => {
  try {
    // Lightweight call — just fetch account info
    await stripe.accounts.retrieve();
    res.json({ stripe: 'ok' });
  } catch (err) {
    res.status(503).json({ stripe: 'error', message: err.message });
  }
});

How to Get Instant Stripe Outage Alerts

A Stripe outage is a revenue emergency. The worst scenario is finding out about it from a customer who couldn't complete checkout, or from your support queue filling up.

Monitor Stripe on Statusfield and get alerted the moment any Stripe component changes status — before your first failed payment notification hits your inbox.

Configure alerts for the components that matter to your business: the API for developers, Webhooks if your fulfillment depends on event delivery, Billing for subscription businesses, and Connect if you run a marketplace.

Start monitoring Stripe →


Frequently Asked Questions

Is Stripe down for everyone or just me?

Check status.stripe.com or Statusfield. If the status page shows operational but payments are failing, check your own error logs first — look for card_declined or card_error codes, which indicate normal card decline logic rather than an outage. HTTP 5xx errors or api_error codes point to Stripe infrastructure issues.

Payments are failing but Stripe's status page shows "operational" — why?

Stripe's status page reflects their internal monitoring thresholds. Partial degradation affecting a subset of users or a specific region may not trigger a status page update immediately. Statusfield monitors Stripe's actual API response times and error rates, which can surface issues faster. Also check: are all payment methods failing, or only specific card types? Some declines are issuer-side and unrelated to Stripe's health.

My webhook isn't firing — is Stripe down?

Check the Webhooks component on Statusfield specifically. Webhook delivery can be degraded independently of the API. You can also check delivery attempts in the Stripe Dashboard under Developers → Webhooks → your endpoint. If you see "pending" events, Stripe is queuing them for delivery when the component recovers.

A payment timed out — was the customer charged?

Possibly. A timeout means you didn't get a response — it doesn't mean the charge didn't happen. Always check the Stripe Dashboard or query the PaymentIntent by ID before retrying. If you use idempotency keys (you should), retrying is safe — Stripe will return the existing result without creating a duplicate charge.

How do I prevent double-charging customers during a Stripe outage?

Use idempotency keys on every charge and PaymentIntent creation. Pass a stable, unique string (like order_${id}) as the idempotencyKey option. If you retry a request that already succeeded, Stripe returns the original response rather than processing a second charge. Without idempotency keys, timeouts during outages can lead to duplicate charges.

Does Stripe automatically retry failed subscription payments?

Yes. Stripe's Smart Retries feature uses machine learning to determine the optimal time to retry a failed subscription payment. During an outage, a payment that fails due to Stripe infrastructure issues may be retried — but check your webhook logs to ensure invoice.payment_failed wasn't incorrectly sent to customers.

How do I get alerted when Stripe goes down?

Set up Stripe monitoring on Statusfield. You can monitor specific components — API, Webhooks, Billing, Connect — and route alerts to email or webhooks, so your engineering and ops teams are notified instantly when any part of Stripe has an incident.