Adobe Journey Optimizer Developer Expert study materials
Adobe Journey Optimizer Developer Expert study resources

The 3am Send That Never Left

Adobe Journey Optimizer Developer Expert · Put your knowledge to work in context.

All case studies

The 3am Send That Never Left

A journey sends a transactional-style 'Your order shipped' email via a custom action. The action calls an external API through a configured data source with a 30-second timeout. On a high-volume night (40,000 entries/hour), 12% of journey entries stall at the action node and eventually error with 'request timeout.' The external API's own logs show requests arriving but responding in 28-35 seconds under load. The journey is configured with a 5-minute wait before the action and a re-entrancy window of 0. Support says 'the journey is broken.' The email provider reports no delivery issues.

1. Is this a Journey Optimizer defect, a configuration issue, or an external dependency issue? Justify with the evidence.

Read the worked answer

It is an external dependency issue surfaced by configuration. Evidence: the external API's own logs show 28-35s response times under load - the bottleneck is upstream, not AJO. The 30s timeout is simply too tight for the API's real-world latency, so ~12% of calls cross the line. AJO is behaving correctly: it honors the timeout and errors the node. The 'journey is broken' framing is wrong; the journey is faithfully reporting an upstream SLA miss. The fix is not in the journey canvas.

2. What changes would you make, and in what order, to reduce the failure rate without dropping messages?

Read the worked answer

Order matters. First, raise the action timeout to comfortably exceed observed p95 (e.g., 45-60s) - cheap, immediate. Second, add a retry with backoff on the action so transient slowness doesn't drop the message. Third, address throughput: 40K/hour hitting a struggling API amplifies latency; consider throttling journey entry or batching. Fourth, if the external system can't meet SLA, move to an async pattern (fire-and-forget with a status webhook) rather than synchronous blocking. Do NOT simply add a longer wait before the action - that shifts timing but doesn't fix the 28-35s response under concurrent load. Validate each change against a load test, not a single manual send.