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 three places:
- On the message itself. The failed message carries a status indicator, same as before, with a hover tooltip.
- In a banner above the composer. As soon as a conversation has one or more failed outbound messages, a banner appears naming the count — “A message in this conversation failed to send” or “N messages in this conversation failed to send.” The banner sits outside the composer on purpose: a conversation with failed sends is often one you can’t reply on anyway, and that’s exactly when you need the way through to the reason.
- 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.
All three 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 any of them.
Opening the Deliverability log
When the banner’s channel supports it, an Open deliverability button appears next to the count. Clicking it takes you to Settings → Email → Deliverability, with the activity table already filtered to that conversation’s failed sends.
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. SMS and Messenger conversations still show the failure banner (a send can fail on any channel), but there’s no “Open deliverability” 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 banner, but there’s no deliverability row to open for them.
- Sends made before this feature shipped can’t be filtered by conversation. The link between a failed send and its conversation depends on data the log did not previously store, and it isn’t backfilled — matching old rows to a conversation after the fact was unreliable, and it would have created a good many wrong links along with the right ones. If you open the Deliverability tab filtered to a conversation and get an empty result, this is very likely why: the table will tell you sends made before this feature can’t be filtered this way and gives you the option to return to the full, unfiltered list.