A flow is failing silently in production. How do you debug it?

"Silently" usually means one of three things: the flow logs an error to the admin email but no user-facing message, an error path swallows the exception, or the flow is succeeding but doing the wrong thing.

Diagnostic steps in roughly this order:

1. Check the Flow's Run History / Paused and Failed Flow Interviews — Setup -> Process Automation -> Paused and Failed Flow Interviews. Failed instances appear here with the input variables and the element that failed. This is the fastest path to the actual error.
2. Check the admin error email — by default failed flow interviews email the user who last modified the flow with the stack trace and variable values. If that email is going to a personal inbox no one checks, fix that first (Setup -> Process Automation Settings -> Default Workflow User -> point to a monitored alias).
3. Reproduce in a sandbox with debug log — turn on a debug log for the running user, run the same input. The flow's element-by-element execution shows up in the debug log under FLOW_ category lines. You see exactly which element ran with what inputs and outputs.
4. Use Flow Builder's Debug Run — if reproducible, run Debug from Flow Builder. You can step element by element with full variable inspection. Caveat: Debug uses fake data unless you tick "Run flow as another user" or "Pass in records".
5. Check Fault Connectors — if the flow has fault paths going to Do Nothing, an error is being swallowed by design. Replace the dead-end fault connector with one that updates an error log object or sends a custom notification.
6. Check governor-limit hits in production specifically — flow runs in production may hit governor limits that don't fire in a tiny sandbox. Look for "Too many SOQL queries" or "CPU time limit exceeded" patterns in the debug log; this is usually a non-bulkified loop with a Get Records inside.
7. If still mystery — wrap the suspect element in a try-catch (Subflow with error path) that logs to a custom Flow_Error__c object. That gives you persistent error rows you can query and graph instead of relying on email.