We truly apologize for the frustration this issue has caused. As you can read on our status page, the us1 zone had execution and login issues yesterday.
Our engineers provided a fix, and everything should be up and running now.
Unfortunately, the “issues were fixed” is not sufficient. We have 30+ clients using Make and when something like this happens, what are we supposed to tell our customers?
Why does Make not provide the actual cause and the solution?
Honest question mate. What good is actual cause and solution though? 99% of my clients are completely clueless as to what Make does and for them its just some magic happening in the background. So even if I give them the actual cause of why there was an outage, they’d still not understand.
Like “there was a bug in the DNS service causing a routing issue, our engineers manually patched the list and fixed it” is a meaningless statement unless you are an IT guy, but then why are you using someone else to build your Make flows or use Make at all?
So regardless if you have the actual info or not, what’s the difference?
@Stoyan_Vatov I agree, for the most part that would be the case, but some of our clients have internal IT/Dev teams to which we have to report.
We’ve been using Make for over 5 years and recent outages are concerning. The fact that Make does not want to share the details, makes me wonder if these issues could have been avoided if proper procedures were in place. At times, it almost feels like the entire infrastructure is running on a “single server”, because every single service goes down for a specific region i.e us.make.com.
I’m okay if the scenarios are not running for an hour or so, but with every outage here’s data loss (webhooks fail to accept data) then there’s a problem.