1. Boundary
Sent to Clay to timeout or reviewed late return
This boundary starts when the payload is sent toward Clay and stays open while the run waits for a result. It ends only when the callback returns on time, the run is timed_out visibly, or a late callback is reviewed safely.
2. Question
Is timeout visible when the result does not return in time?
A Clay enrichment timeout boundary is useful when it answers one question quickly: is this run still waiting_for_result legitimately, or should it already be visible as timed_out, manual_review, or late callback held for review?
3. Risk
Timeout is a state boundary, not just an error label
waiting_for_result never resolves
A Clay enrichment timeout boundary fails when waiting_for_result stays open indefinitely and nobody can tell whether the result is still expected or already lost.
timed_out is not written
Without timeout_at and a visible timed_out state, the handoff can fail silently after the original send succeeds.
Late callback is mistaken for normal completion
A callback that arrives after expected_callback_by should not erase the timeout history. It should be held for review before replay or delivery.
Blind replay causes duplicate side effects
Retry or replay without review can create duplicate writes, duplicate alerts, or conflicting downstream state when the late result finally appears.
4. Minimum fields
Timeout visibility needs timestamps, state, and alert evidence
run_id The internal run identity that stays open while the Clay result is still expected.
source_event_id The upstream event identity tied to the same waiting run.
sent_to_clay_at When the payload actually left the receiver and started the timeout window.
expected_callback_by The expected time boundary for callback receipt based on the chosen operating window.
callback_received_at When the result returned, if it returned at all.
timeout_at When the waiting run was marked late instead of staying open forever.
current_state The visible run state such as waiting_for_result, timed_out, or manual_review.
alert_state Whether a Slack timeout alert was sent for the state change.
retry_count How many controlled retries or replays have been attempted after timeout review.
5. Suggested check
Make timeout visible before recovery starts
A timeout boundary works best when the system writes timeout state first, alerts on that state, and only then considers whether retry or replay is safe.
sent_to_clay -> waiting_for_result -> timed_out -> manual_review / callback_received_late -> replay_reviewed- Move the run to waiting_for_result immediately after sent_to_clay_at is recorded.
- If callback_received_at is still empty after expected_callback_by, write timeout_at and move current_state to timed_out or manual_review.
- Send a Slack timeout alert only when the timeout state is actually written.
- Hold late callbacks for manual_review instead of treating them as normal completions automatically.
- Block retry or replay until the timeout state and callback history are reviewed together.
- Keep Clay enrichment timeout visible as its own handoff boundary rather than a hidden implementation detail.
6. No GTM logic required
Timeout can be reviewed without exposing the full system
You do not need to reveal scoring, routing, or downstream sales logic to know whether the result returned inside the expected window. The timeout boundary stands on its own.
- No lead scoring rules are needed to know whether waiting_for_result has timed out.
- No routing logic is needed to know whether a Slack timeout alert should fire.
- No sales process details are needed to block retry or replay until review finishes.
- No full GTM workflow required. Clay Relay only checks the handoff boundary.
7. Synthetic example
Waiting run, timeout transition, alert, late callback, and blocked retry
Every value below is synthetic. The example shows how a waiting run becomes timed_out visibly, triggers a Slack timeout alert, holds a late callback for manual review, and blocks retry until the boundary is reviewed.
{
"run_id": "cr_run_20260630_901",
"source_event_id": "evt_synthetic_901",
"sent_to_clay_at": "2026-06-30T11:00:00Z",
"expected_callback_by": "2026-06-30T11:03:00Z",
"callback_received_at": null,
"current_state": "waiting_for_result",
"retry_count": 0
}{
"run_id": "cr_run_20260630_901",
"expected_callback_by": "2026-06-30T11:03:00Z",
"callback_received_at": null,
"timeout_at": "2026-06-30T11:03:04Z",
"current_state": "timed_out",
"alert_state": "timeout_alert_sent"
}{
"run_id": "cr_run_20260630_901",
"state_change": "timed_out",
"slack_channel": "#ops-synthetic",
"alert_state": "timeout_alert_sent",
"next_action": "manual_review"
}{
"run_id": "cr_run_20260630_901",
"callback_received_at": "2026-06-30T11:04:31Z",
"timeout_at": "2026-06-30T11:03:04Z",
"current_state": "manual_review",
"note": "late callback held for review"
}{
"run_id": "cr_run_20260630_901",
"retry_count": 0,
"current_state": "manual_review",
"replay_allowed": false,
"reason": "timeout boundary unresolved"
}9. What Clay Relay would track
The timeout layer is about visibility, alerts, and safe recovery
waiting_for_result opened
Whether the run entered waiting_for_result immediately after the Clay handoff started.
Timeout transition
Whether timeout_at and current_state were written when expected_callback_by passed.
Slack timeout alert
Whether alert_state confirms a Slack timeout alert tied to the timed_out state.
Late callback held
Whether a late callback stayed visible for review rather than silently normalizing the run.
Retry blocked until review
Whether retry_count stayed controlled while the operator reviewed timeout and callback history together.
Replay safety
Whether replay stayed blocked until the timeout boundary was understood and safe to recover.
10. CTA
Check the timeout boundary before the run disappears into silence
We can review one Clay enrichment timeout boundary, show where waiting_for_result, timeout_at, alert_state, late callback handling, or replay safety is still fragile, and keep the review scoped to that handoff only.