Fault Handling Flowchart
The code
flowchart TD
A[Request received] --> B[Call upstream service]
B --> C{Call succeeded?}
C -- Yes --> D[Return response]
C -- Timeout --> E[Retry with backoff]
C -- Error --> F[Check retry budget]
E --> G{Retries left?}
F --> G
G -- Yes --> B
G -- No --> H[Serve cached response]
H --> I[Log degraded mode]
D --> J((Request complete))
I --> J
How this template works
This template documents the resilience behavior of a service that depends on something unreliable. Instead of a happy path with a vague failure arrow, it spells out the three questions every client library must answer: did the call fail, do we have retry budget left, and what do we serve when everything else fails. Reliability engineers use it in design reviews to check that a fallback actually exists, and it makes an excellent companion to the retry configuration in your code, because the diagram shows the order of decisions the config only implies.
The syntax demonstrates one diamond with several labeled exits. flowchart TD keeps the decision flow vertical. The diamond C{Call succeeded?} has three outgoing edges: C -- Yes --> D[Return response] for success, C -- Timeout --> E[Retry with backoff] for a slow failure, and C -- Error --> F[Check retry budget] for a fast one. Splitting timeout from error is deliberate — a timeout may have succeeded downstream, so it retries, while a hard error conserves budget first. Both paths meet at G{Retries left?}, whose Yes edge G -- Yes --> B loops back to the upstream call itself, modeling the retry. The No edge leads to the fallback H[Serve cached response], and the step I[Log degraded mode] records that the fallback fired — without that node, the diagram would describe a system that fails silently. The terminator J((Request complete)) receives both the success and the degraded path, which is the honest way to draw it: the request completes either way.
The gotcha is the retry loop target. G -- Yes --> B must point at the call node B, not at the request entry A — pointing at A would redraw the whole request, including any work done before the call. When editing, trace the loop edge and confirm it re-enters at the exact step that failed. Also keep the three exit labels distinct; two edges labeled Error from the same diamond will render but read as a typo.
Related templates: the incident response flowchart for what humans do when the fallback is not enough, the webhook retry sequence for the same retry idea drawn as a message exchange, and the CI/CD pipeline flowchart for the delivery gates that keep faulty code from reaching this path. The flowchart diagram guide has the complete edge syntax.
Variations to try
- Add a circuit breaker diamond before the upstream call that skips the call while the breaker is open.
- Replace the cached response with a queue-and-notify step for write paths that cannot serve stale data.
- Change the timeout label to your real budget, such as 200 ms, so the diagram matches the config.
