So the outage happened and I’m curious about what happens to the webhooks that were sent to the server in that period of time?
I am wondering about the same thing. I have just migrated from Zapier and whenever there was an outage. The data sent to the webhook was still stored, then sat in a queue until operational again. So no lost data.
However, as it was a full server outage I fear that anything sent to the scenarios in that period have been lost.
I hope I am wrong, but can’t see any queued items appearing on my side.
Thanks
Craig
webhooks are being Accepted now but scenarios are not triggering from those webhooks
I’m pretty sure all the webhook queue data is lost. The hook URL was returning a “web server error”.
The same issue happened back on July 23rd, where the service was completely down and none of the webhooks worked (again, data loss).
Honestly, it feels like MAKE is running everything on a single server, if something goes wrong - the whole infrastructure goes down.
The most frustrating part is that the webhook data has been lost and it is going to take a while to get the systems back in sync.
Shame on you Make.
1 Like
So everything is lost? We have thousands of automations and webhooks, how should i now go back and trigger all of them again?
This is definitely not acceptable and needs to be fixed, i can’t accept that.
This means a huge money loss for us
1 Like
Hello everyone @here, thank you very much for raising this in the community.
We’re deeply sorry for this outage and the disruption it caused. We know it may have had a serious impact on your work.
For more information about how your scenarios may have been impacted, and to see what action you should take, please refer to this help article.
There is NO info in Make official email about what happened and what will be done to prevent this.
I 100% agree with @vtexperts that Make needs to have redundancy for webhooks. Having to go to the app that sent the webhooks, make an inventory of lost webhooks and refire is not a solution, it is not even a fix. Most apps don’t have a way to see webhook history and even less have the ability to replay them.
1 Like
1 Like
Absolutely, Michaela — you’re hitting on a critical point…
Make has become a mission-critical backbone for many businesses, and the reality is that even a short outage can have cascading effects. A day or a week of downtime isn’t just theoretical — it’s something businesses have to plan for, because lost webhooks = lost data = lost trust with clients. Asking customers to figure out what data was lost and to retrigger webhook events is simply unrealistic. Even most make partners can’t do this for our clients since many systems don’t have selective retriggering of outbound webhook events.
Queueing systems aren’t new; they’re a proven method for mitigating outages. By buffering events outside of Make infrastructure itself, you can ensure that data isn’t lost if a webhook fails or the platform goes down. Implementing this at scale is complex, yes, but it’s increasingly essential for any system that businesses rely on in real time.
From a user perspective, it would be hugely reassuring if Make were transparent about their strategy for catastrophic downtime and invested in robust, external queuing infrastructure for webhooks. Right now, the risk is borne entirely by users, and that’s a lot to manage when your operations depend on flawless automation.
It’s not just about avoiding minor inconveniences — it’s about ensuring business continuity and resilience in the face of inevitable infrastructure failures.
As an automation leader Make can make a terrific name for itself if they address the eventual multi-hour catastrophic downtimes that may, nay will, happen.
1 Like
I appreciate that overall downtime was just a few hours, but like others are saying, there really needs to be some kind of webhook queue backup. I guess I could put additional webhooks on my bigger projects and have the payloads archived externally, but that seems pretty silly for a product that is supposed to be operating at an enterprise level.
I’m fine with re-running a scenario to pickup the queue backlog if needed. Beyond that I think Make needs to come up with a solution.
1 Like
The alert email/article published did not include any information as to what was the cause, solution and assurance this will not happen again.
You have 350K+ customers and there is no transparency? I can’t image your customers are just fine with that.
2 Likes
Are there still problems ongoing? I have strange behaviour im some MySQL-Modules. Already contacted support. It uses different usernames for the same MySQL Connection in the same Scenario - in another scenario I´ll run into an error which says wrong parameter value and its the source data is completely fine and the same as 5 days before.
Anyone else still having problems?
Auto-disabling webhooks is obviously not an adequate solution to whatever problem you’re having at Make.com where you need to disable unused webhooks. You’re just causing problems for people. Just resolve the issue with an intelligent solution that doesn’t cause more problems.
Hello everyone, please know that we fully understand your frustration.
Below, you’ll find information that explains how Make Webhooks work with a sending party in the event of an error.
-
Make’s Webhooks have a solid queuing mechanism for inbound calls. They can buffer up to 10,000 calls each. You can monitor such capability from your Make Webhooks section.
-
In the event of a critical error affecting Make’s inbound queueing mechanism, most of sending parties usually rely on their own retry mechanism to secure the delivery of failing calls over a span of several hours.
This explains why you might have received delayed inbound calls to your webhooks as remote parties had buffered them during the outage.
We regret disruptions in any form, and we will work hard to avoid similar situations in the future.
Should you need any help, do not hesitate to reach our to our Customer Care team.
How would a customer know if their app has a retry mechanism to retry failed webhooks?
Martin Cizler, Vice President, Engineering
As you may be aware, we experienced a platform outage on 4 September 2025 between 14:37 CEST and 16:35 CEST that affected the execution of all scenarios. You can find details on how your scenarios may have been impacted here.
We know that Make is important to your business and while situations like this are very rare, we take them extremely seriously. Thanks to our extensive monitoring and rigorous incident response procedure, our engineering team responded within minutes to mitigate the impact and restore the service as fast as possible.
In the hours immediately following the outage, we also conducted a thorough investigation, reconstructed the complete chain of events that led to the incident and worked round the clock to implement a range of proactive measures to defend against a disruption like this from happening again - with additional hardening steps planned for the near future.
Thank you for your continued support - and rest assured that we’re here to help. If you experience any issues please feel free to reach out to our Customer Care team.
3 Likes
Thanks for chiming in. Can you disclose what proactive measures have been taken without getting into too many details?