Requesting a "retry" button for campaigns: When a campaign fails to send to a subset of subscribers due to a transient error
Is your feature request related to a problem? Please describe.
When a campaign fails to send to a subset of subscribers due to a transient error (like a network issue or an SMTP timeout), the system currently marks the campaign as "finished." This status is misleading because delivery was incomplete.
There is no built-in mechanism to identify which subscribers were affected by the failure or to re-attempt sending to them. This leaves a critical gap in campaign management.
Example Scenario:
- An important campaign is sent to 1,000 subscribers.
- During the sending process, a temporary network outage causes SMTP connections to time out for 150 of those subscribers.
- The system attempts to send, fails for those 150, but succeeds for the other 850.
- The campaign is marked as "finished."
- System logs may show the error, but they can be difficult to parse or may be cleared before an administrator can review them.
Impact: The user is left with an incomplete campaign and has no way to know which 150 subscribers did not receive the email. They cannot ensure a critical message was delivered to everyone on the list, and manually cross-referencing is impossible for large lists.
Describe the solution you'd like
To resolve this, I propose adding a robust failure-handling mechanism. This could be implemented in one of two ways:
Solution A: Campaign Retry for Failed Subscribers (Ideal)
Introduce a "Retry Failed" function for completed campaigns.
- How it would work: Next to the campaign status icon (e.g., the rocket), a "Retry" button would appear if any subscribers failed to receive the email.
- Action: Clicking this button would automatically queue the campaign for resending, but only to the list of subscribers for whom the initial delivery failed. This provides a simple, one-click solution to ensure complete delivery.
Solution B: Failed Subscriber Visibility (Alternative)
If a full retry feature is not feasible, provide a way to identify the subscribers who were missed.
- How it would work: In the campaign report/statistics view, add a new tab or filterable status called "Failed."
- Action: This view would list all subscribers for whom the send failed, allowing the user to see exactly who was affected. From here, the user should be able to export this list. With this export, they can manually create a new list and clone the original campaign to target only the failed recipients.
EDIT
Proposed Technical Implementation: A campaign_send_logs Table
The root of the solution is to create a new table in the database, for example, campaign_send_logs. This table would create a record for every single send attempt.
Schema Idea:
id(Primary Key)campaign_id(Foreign Key)subscriber_id(Foreign Key)status(An enum: 'sent', 'failed')error_message(Text field to store the SMTP error, e.g., "Connection timed out")created_at(Timestamp)
Benefits of this approach:
- 100% Accuracy: Provides an exact, auditable record of every send attempt and its outcome.
- Easy Identification: Finding failures becomes a simple database query (
SELECT * FROM campaign_send_logs WHERE status = 'failed'). - Enables New Features: This backend data makes it possible to build the following user-facing features reliably.
User-Facing Feature 1: Campaign Retry for Failed Subscribers
Based on the new log table, a "Retry Failed" function should be added to the campaign dashboard.
- How it would work: If a campaign has entries in
campaign_send_logswith a 'failed' status, a "Retry" button would appear. - Action: Clicking this button would query the log table for all failed
subscriber_ids for thatcampaign_idand automatically queue the campaign for resending only to that specific group.
User-Facing Feature 2: Failed Subscriber Visibility
In the campaign report/statistics view, add a new tab or filterable status called "Failed."
- How it would work: This view would be populated by querying the
campaign_send_logstable for all 'failed' entries related to the campaign. - Action: It would display the subscriber's email, the timestamp of the failure, and the
error_message. It should also include an option to export this list as a CSV. This allows users to manually manage re-sends or analyze the root causes of failures.
I think the main reason something like this wasn't implemented was to keep database sizes small. But we have the "maintenance" section. Couldn't we just add an option to purge send logs there?
If database size is of concern then a purge campaign_send_logs button would be sufficient.
Follow Up:
I have been trying to use the query function and I was successful! So basically if you go to subscribers -> click on the list which failed and then use the query NOT EXISTS(SELECT 1 FROM campaign_views WHERE campaign_views.subscriber_id=subscribers.id AND campaign_views.campaign_id=<put_id_of_campaign>) you will get all subscribers from a specific list, which didn't viewed the mail. In my case that was enough to mark them and push them into a new mail and start the same campaing with my new settings.
However I still think a retry button to restart a campaing with subscribers which didn't recieve the mail would be great. Also the logs only show the ID from the database not the email itself which could also help alot.
This is something I also would be very interested in, as I encountered this today. Only a third of the subscribers got the mail due to smtp issues. Now I have no other choice but to resend the campaign with the side effect, that one third will receive a duplicate of the mail.
Same here. My latest campaign ended like this: 2,896 / 20,081 and is marked "Finished".
Well, it is not finished and should not have been marked finished so this issue is multi layered.
- Campaign cannot be marked as "Finished" until all the recipients have been emailed. If sending is impossible we need a new status, for example "Error" or "Incomplete" with a possibility to "Resume"
- We need a direct way for at least seeing who we emailed before the campaign failed to finish. Right now it is very convoluted.
@vmajor what is your listmonk version?
I am on v5.0.3, maybe I should update. I see that we are now up to 5.1
EDIT: is the "Check for updates Periodically check for new app releases and notify." feature a placeholder? It did not notify me of the new release.
This issue sounds potentially quite concerning, especially for large lists of participants. At what point would listmonk give up sending a campaign?