What happens when Stripe, email, or your AI API goes down?
Your app almost certainly doesn't do everything itself. Something else takes the payment. Something else sends the confirmation email. Something else checks the password, or answers the AI prompt. Your agent may have wired several of these in while building, sometimes without making the dependency particularly visible to you. Most non-technical founders I talk to can't actually name them.
That's fine, most of the time. It stops being fine the moment one of those services is slow, returns an error, or goes offline, and your app has to decide what to show a real person in that moment. I often find that the failure behavior hasn't really been decided yet. The app just hasn't hit that moment yet.
01 — What is it?
An external service is anything your app asks another company's computer to do for it. The clearest way I've found to explain what that request actually is: think of your app as a customer at a restaurant, and the external service as the kitchen. Your app doesn't cook the meal — it hands a waiter (the API) an order, the waiter carries it to a kitchen it doesn't control, and eventually a plate comes back, or doesn't.
Four kinds of external service show up very often in AI-built apps:
- Payments — usually Stripe, sometimes Paddle or a similar processor. It moves the money and tells your app what happened.
- Email — a sending service like Postmark, Resend, or SendGrid. It delivers the confirmation, the receipt, the password reset.
- Auth — a login provider, or a chunk of it, handling passwords, sessions, or "sign in with Google."
- AI — the model API your product itself calls, separate from the AI tool you used to build the app.
You don't need to understand how any of these are wired in. You need to know that they exist, and that a waiter can drop a plate, get the order wrong, or bring one twice.
02 — Why should you care if you don't code?
Because when the kitchen is closed, your user doesn't blame the kitchen. They blame the restaurant. Stripe having a bad ten minutes, or your email provider silently rate-limiting you, isn't a fault in your app in any sense that matters to the person hitting "pay now." It's not your fault, and it's still your problem — the failure surfaces as your product being broken, on your watch, in front of your customer.
The sharpest version of this, and the one an AI-built app is least likely to be guarding against, isn't "the payment failed." It's the payment succeeding while your app thinks it failed.
Here's how that happens. Stripe doesn't just take the payment — it separately sends your app a notification (a "webhook") confirming the charge went through, and your app is usually the thing that updates its own records off that notification, not off the payment itself. If that notification is lost or delayed, the two records can disagree: Stripe has the money, your app still shows the order as failed. If the app handles a duplicate event incorrectly, it may process the same successful payment twice internally.
Source: Stripe's own webhook documentation covers exactly this — duplicate events and delivery retries are expected behavior, not an edge case (Stripe — handling duplicate webhook events).
An agent building toward "the happy path works" has no particular reason to think about the notification failing separately from the payment failing — they feel like the same event from inside a chat window where everything looks like it worked. They aren't the same event, and the gap between them is exactly where a customer ends up charged with no order, or worse.
03 — What does good look like?
Not a circuit breaker. Not a retry queue. Good, at this stage, is much smaller: for every external service your app calls, there's an answer you or your agent can actually state out loud for "what happens if this one fails right now." Even if the honest answer is "nothing — it just breaks and the user sees an error," that's a real answer you can act on. "I don't know" is the only wrong one.
A useful shape for that answer is degraded, not dead. Chrome's own offline page still lets you play a small dinosaur game instead of showing a blank error — the browser stayed useful even though the network didn't. Checking email in airplane mode works the same way: your mail app shows you the last inbox it synced and queues anything you draft, rather than pretending you have no email at all. Neither example hides the failure. Both keep the person in front of the screen doing something sensible instead of staring at a dead end.
Source: Stripe frames the same idea for payments specifically — plan for the gateway being unreachable rather than assuming it never happens (Stripe — what to do when your payment gateway is down).
Monitoring is the other half. A pattern I still see is that the first alert is an unhappy customer email. Nothing was watching production, so nothing told you first. The fix for that isn't a full observability stack — you don't need to evaluate Sentry versus Datadog versus Better Stack before you launch. The floor is much lower: one alert, to your inbox, when something breaks in production. Think of it as a check-engine light, not a mechanic's full diagnostic bay — or a flight data recorder, a diary the app keeps of what went wrong and when, so "it broke" has a timestamp and a cause instead of just a customer's memory of "it didn't work yesterday."
Source: the practical distinction between logging (the record) and alerting (the thing that actually taps you on the shoulder) is laid out clearly in Better Stack's guide (Better Stack — observability vs. monitoring); OWASP's own guidance is the authoritative baseline for what's worth logging and how to handle errors safely in the first place (OWASP — Logging Cheat Sheet, OWASP — Error Handling Cheat Sheet).
One more thing worth checking, separate from whether monitoring exists at all: an agent can add a monitoring line of code once and never confirm it actually fires. A tool being installed and a tool being configured to reach you are two different claims — verifying the second one is part of clearing this floor, not an optional extra.
04 — What can you safely ask your AI agent?
These are two different diagnostic questions, on purpose, and I'd rather you run them separately than collapse them into one. The first is about what your app does when something it depends on fails. The second is about whether anyone would find out. An agent can answer either one honestly without touching a single line of code — and a search that comes back empty is not the same claim as "there's nothing there." If your agent can't find a fallback, or can't find any monitoring, the honest answer is "I couldn't find one," never "there is none."
List every external service this app calls (payments, email, auth, AI). For each, show what the app does if it times out or returns an error — or tell me you couldn't find any handling for that case. Don't change anything.
Read what comes back before you touch prompt two. A short list with a stated behavior next to each entry — even an honest "no handling found" — is exactly what section 3 describes as a real answer.
Is there any error monitoring or logging that would alert me when something breaks in production? Show me where it's configured, or tell me you couldn't find any — don't assume production is monitored. Don't add anything yet.
Read both answers, don't act on either yet. Together they tell you where you actually stand — not what "should" be there, what's really there — and that's the honest starting point for deciding what, if anything, needs to change before you launch.
This is one article in the Launch Readiness KB series — it walks through what a Trust Report scan actually looks for before you launch, hire, or raise on an AI-built app, one concept per article, always ending in something safe to ask your agent, never something that changes your code.