Troubleshoot a failed email send
When an outbound email fails, Atender no longer leaves you with just a warning icon on the message. You can now jump straight from the conversation to the Deliverability activity log and see exactly why the send failed — the error code, the reason, and every other attempt to that same recipient.
Where a failure shows up
A failed send now surfaces in two places:
- On the message itself. The failed message carries a status indicator, same as before, with a hover tooltip. Next to it are the actions for that send: Send this message again (email only) and See why it failed. A conversation with several failures shows the actions on each failed message.
- In the inbox row preview. If a conversation’s most recent outbound message failed, its preview line in the inbox is replaced with the same “Failed to send” wording, matching the pill’s color and icon. This is judged off the most recent send only — if a new inbound reply or a later retry comes in, the preview reverts to normal even if the earlier send is still failed.
Both surfaces use the same gate: the message must be outbound and sent by an agent. A failed inbound message (which can’t really happen, but is a status a channel could theoretically report) won’t trigger either of them.
Opening the Deliverability log
When the message’s channel supports it, a See why it failed button (a question-mark icon) appears next to the failed message. Clicking it takes you to Settings → Email → Deliverability, with the activity table already filtered to that conversation’s email activity. Pick Failures only to see just the failures.
A view filtered to one conversation shows its email activity from every sending domain, not just the domain the conversation currently uses, and a banner on the table says so. Every new failure now carries its conversation, so new failures appear in the filtered view without any extra steps.
Only Email and Amazon conversations show this button — those are the two channels that send through Mailgun, so they’re the only ones with a row in the deliverability log to link to. It also shows only to users who can open Email settings. SMS and Messenger messages still show the failed status (a send can fail on any channel), but there’s no See why it failed button, because following it would land you on an email table that can never match.
Using the activity table
Once you’re on the Deliverability tab, filtered or not, you get:
- Search across every failed send, not just the page you’re looking at. Search runs on the server against the same fields the table displays, so a search for an address or an error code checks your tenant’s entire history, not just the fifty rows currently loaded.
- Pagination. The list of failed sends can run into the thousands for an active tenant, so it now pages instead of trying to render everything at once.
- Grouping by recipient. Repeated failures to the same recipient within the list are grouped together, so a recipient whose mailbox is bouncing every message doesn’t fill the table with duplicate rows.
- Status and Detail columns. The Status column now shows the actual outcome of the send (for example, a bounce or rejection), instead of the underlying action name that used to appear on every row regardless of what happened. The Detail column shows the reason the log already captured but never displayed — the specific error text from the provider.
- A When column with room to breathe. Rows from an earlier day show a full date and time; the column is sized to fit that without crowding the Recipient column, and you can still expand a row for the full detail.
Limitations
- Only Email and Amazon (Mailgun) sends link this way. Other channels can fail too, and will still show the failed status, but there’s no deliverability row to open for them.
- Older failures are matched through the send they answer. Failures recorded before conversations were stored on each failure are matched to a conversation through the original send they relate to, so no backfill is needed. If you open the Deliverability tab filtered to a conversation and get an empty result, it usually means the conversation’s original sends predate the conversation link. The table will tell you so and gives you the option to return to the full, unfiltered list.