The failure modes that actually happen
A downstream API (Telegram, a CRM, an email provider) times out or returns an error; a network blip drops a request mid-flight; a rare malformed input breaks a parsing step. These aren't hypothetical — they're the ordinary failure modes of any connected system, including this site's own.
What a handled failure looks like
A timeout with a limited, safe retry for genuinely transient errors, an honest error message to the user instead of a false success, and a server-side log with enough detail to recover the lead — without logging personal data in plain text unnecessarily.
What a silent failure looks like — and why it's worse
The dangerous version: the user sees "success" while the message never actually arrived anywhere. This is a real, previously-existing risk pattern worth testing for directly — see How to Test an AI Agent Before Launch for how to catch it before launch.
This site's own honest limitation
There is currently no separate database persisting leads if Telegram delivery fails — a failed delivery is recoverable from server logs, not from a dedicated backup store. See AI Intake Security & GDPR for the full, honest picture of this limitation.
Questions
What happens to a lead if delivery fails?+
It's logged server-side (without full personal data) and the user is shown an honest error with an alternative contact method — not a false success message.
Is there automatic retry?+
Yes, a limited retry for errors that are plausibly temporary — not for errors that would fail identically every time.
Does this mean leads can be permanently lost?+
In a rare worst case with no persistence layer, yes — this is an honest, current limitation, not a hidden one.