# Failed webhook retry (button or queue)
**URL:** https://forum.mautic.org/t/failed-webhook-retry-button-or-queue/36993
**Category:** Ideas and Feature Requests
**Tags:** development
**Created:** [November 28, 2025, 2:17pm UTC](https://forum.mautic.org/t/failed-webhook-retry-button-or-queue/36993 "2025-11-28T14:17:15Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@woutersf](https://forum.mautic.org/u/woutersf)
#### Post date: [November 28, 2025, 2:17pm UTC](https://forum.mautic.org/t/failed-webhook-retry-button-or-queue/36993/1 "2025-11-28T14:17:15Z")
**My idea comes from pardot / salesforce.**
When pushes (webhooks) to remote systems fail in other systems It automatically retries.
But not after a fixed amount (because when the endpoint comes back up it would immediately go down again with all the retries).
This is why it would do exponential backoff.
Retry after 1 min / 1 hour / 1 day / failed
**I think these groups of people would benefit from this idea:**
Existing salesforce/pardot users
**Why I think they would benefit from this idea:**
- Feature parity
- It makes sense to have the webhooks retry when failed
- Also now you dont see it when webhooks fail, I think we should notify the user.
Any code or resources to support this idea:
Are you willing to work on this idea?: yes
What skills and resources do you need to explore this further?
Not sure.
i’d suggest
1. Guzzle backoff retry (if not there already)
[Backoff retry plugin — Guzzle documentation](https://guzzle3.readthedocs.io/plugins/backoff-plugin.html)
2. A button to manually retry a failed call
3. A notification to the user when \>1 request failed in the last minute. (X Webhooks failed in the last hour) SO you can go click it when the backend is up again.
---
### Author:  [@bastianhammer](https://forum.mautic.org/u/bastianhammer)
#### Post date: [November 30, 2025, 7:07am UTC](https://forum.mautic.org/t/failed-webhook-retry-button-or-queue/36993/2 "2025-11-30T07:07:03Z")
Hello Frederik,
thanks for this idea.
I’m using Mautic webhook heavily with n8n / SuiteCRM and other system integrations.
The current fire and forget approach is simple and works as long as everything works.
Especially with customer data in external systems (CRM / CDP) and external calculations / logic implementations / workflows, a solid integration is required.
Integration monitoring as well - it’s best to proactively fix things and not hear issues from your customers feedback (or read about it on review pages / social meadia).
To start super simple, I’d start with your suggestions 2 & 3.
For 2: Where would you see the button? The queue would need to be enabled and there needs to be a visualization of the queue in order to see failed attempts and manually retry them?
As for 1: A queue and retry mechanism would be great. Probably best to split up this part since this could be a project in itself.
---
### Author:  [@woutersf](https://forum.mautic.org/u/woutersf)
#### Post date: [December 2, 2025, 7:36am UTC](https://forum.mautic.org/t/failed-webhook-retry-button-or-queue/36993/3 "2025-12-02T07:36:28Z")
 I was thinking on this screen to add a button to retry it (that would be a first attempt)?
I was reading more and apparently guzzle has a sort of retry mechanism built in. Perhaps we already have this implemented without knowing?
---
### Author:  [@woutersf](https://forum.mautic.org/u/woutersf)
#### Post date: [December 2, 2025, 7:43am UTC](https://forum.mautic.org/t/failed-webhook-retry-button-or-queue/36993/4 "2025-12-02T07:43:05Z")
The code that does the post:
>
Example Middleware for doing retries automatically
> **[GitHub - caseyamcl/guzzle\_retry\_middleware: Middleware for Guzzle v6/7+ that automatically...](https://github.com/caseyamcl/guzzle_retry_middleware)**
>
> Middleware for Guzzle v6/7+ that automatically retries HTTP requests on 429, 503 responses.