Sad path / unhappy path
Published Updated
What is Sad path / unhappy path?
The sad path (or unhappy path) is everything that happens when a flow goes wrong: errors, invalid input, missing data, timeouts and other exceptions. It is the opposite of the happy path, where everything works.
The parts of a flow where something goes wrong, including errors, invalid input, missing data, timeouts, and other exceptions.
The sad path covers what happens when a process does not go smoothly. It is where teams learn whether the product recovers gracefully, gives clear messages, and avoids losing user work.
How it relates to Orbit
Orbit’s validation pass catches one sad path of agent work, a run that reports success without a real change, and labels it a ghost ship. See Ghost Ships & Validation for details.
When you would use it
You use sad path when you are thinking about everything that can break, not just the ideal success route.
Common operations
- Testing invalid inputs
- Designing error messages
- Handling retries and recovery
Frequently asked questions
Why test the sad path?
Most real bugs live there. Testing it shows whether the product recovers gracefully, explains what went wrong, and keeps the user’s work instead of losing it.
What is a sad path in AI-agent work?
A common one is an agent that reports success without making the change. Orbit’s validation pass checks the commit diff after every run and labels that outcome a ghost ship. See Ghost Ships & Validation.
Is “unhappy path” the same as an edge case?
They overlap. An edge case is any unusual input or state; the unhappy path is specifically the route a flow takes when something fails.
Related terms
Where this is taught
No learning path uses this term yet. Browse the Learning Atlas for guided sequences through related ideas.