Use this as a general approach any time something in a multi-step pipeline fails and it's not immediately obvious which step is actually at fault.
Steps
- Isolate. Find the smallest unit that can be tested on its own, one node, one function, one API call, rather than re-running the entire chain and guessing from the end result.
- Read the real error, not the summary. A short error message like "Bad request" or "Connection failed" is rarely enough to fix from. Look for the full detail: the actual request sent, the actual response received, the actual stack trace. The real cause is almost always visible there, even when the summary is vague.
- Fix one thing at a time. When multiple things look suspicious at once, change one, retest, then move to the next. Changing several things simultaneously makes it unclear which change actually mattered if the retest passes.
- Confirm the fix actually took effect before moving on. Some platforms distinguish between saving a change and publishing it live, confirm you're testing the current version, not a fixed-but-not-yet-live one.
Gotcha
The instinct under pressure is to change several things at once, hoping one of them fixes it. This usually costs more time overall, since a passing retest doesn't tell you which change mattered, meaning the same confusion returns the next time something similar breaks.
Quick reference
Isolate the smallest failing unit
↓
Read the full error detail, not the summary
↓
Change one thing
↓
Confirm the change is actually live
↓
Retest