Constant 503 RuntimeErrors at trigger Microsoft Outlook Calendar 'Watch Events'

Hi all,

Hoping to get some insight, because at this point I’m having a really difficult time dealing with this and am at a complete loss of where to go from here.

I’m running close to 100 scenarios, each using a Microsoft 365 Calendar Watch Events trigger pulling from a different shared Calendar ID with the same account by Updated Time, and all using two filters to scan the Subject for words “x” or “xx” and Limit 50 results to be returned and pulled into a task management program to be read line by line. Each scenario is scheduled to run once a day, 5 minutes apart from ~10pm - 6am.

Those that run successfully, the process is beautiful. I see what I need to see in the output program, but the problem is not with those that run, but those that fail. And, boy, do they fail.

Every single morning I wake up to about 40% of the scenarios notified with a 503 RuntimeError, and most of them shut down since these errors happen constantly when run. I’ve changed the “Limit” to a smaller number, and no changes, still the timeout error. I want to pull my hair out at this point, and the process of going through each one and manually rerunning them one-by-one is maddening, and am realizing this process is causing me and my colleagues more wasted time and work troubleshooting and manually rerunning these scenarios. I dread checking my email in the morning now to these messages of errors.

Has anyone ever run into this issue and resolved it?

Thank you

An HTTP 503 error always occurs when a server can’t deliver the requested resources at the time the client requests them. There are three possible reasons for this:

  1. The server is in maintenance, such as bringing in updates, securing databases, or creating backups and is therefore not connected to the internet during these processes.

  2. The server is overloaded, meaning that is it receiving more requests than it can handle. This is why it responds with the error message. There are many reasons for an overload to occur: often an unexpected increase in traffic is the cause, but also when a web project continues to grow it can cause an overload if resources aren’t upgraded at the same time. Other possible reasons are malware/spam attacks as well as web applications or the content management system being incorrectly programmed.

  3. In rare cases, an incorrect DNS server configuration on the client side (computer or router) may result in an HTTP 503 error message. The selected DNS server itself might temporarily have problems, which then results in the HTTP request showing a ‘Service Unavailable’ message.

So this is totally beyond your control. Make will retry your warnings or you can add an error handler and customize the appropriate set of steps to take.

100 scenarios sounds like you’re also being throttled by m365 api. Why so many?


Thank you for your detailed response.

We were at one time receiving throttling errors, but had since scheduled the scenarios to run 5 minutes apart, and there have been no more 429 errors. 100 scenarios because that’s how it was built by a hired Make expert, so I can’t really answer that. His answer to the 503s were to rerun it. Well, that’s not really a solution if we have to individually manually rerun these every single day. The frustration level at this point is out the door.

This morning there were 23 notifications with the 503, and 6 scenarios that were stopped due to repeated 503s.

Is there a way to make a scenario run successfully at the Outlook 365 Watch Events trigger at the point of error with a [503] over and over until it succeeds, similar to an automatic press of ‘Run’? There has to be.

There is — use error handlers effectively.

Hello, My name is Alex Sirota and I am the founder of NewPath Consulting. We are a 4-year old partner. We offer a one hour video call where we explain and show how Make can help your organization. We even build some scenarios and share them with you so get more value than a usual exploratory discussion. Book some time with me at Hero - NewPath Consulting I look forward to talking to you and your team should they join us.

I am not an expert, so I tested a Break handler at the trigger, and I think it worked when it succeeded?.. although it seemed to stop every single scenario scheduled after that. And since it was one of the early scenarios, all the rest never ran after as scheduled after that until I removed the handler. It was bizarre.

Break just breaks at the error and stops the scenario flow. Not sure you want that. Ignore will continue. You could place other modules before the break.

1 Like

But the Ignore won’t rerun the scenario over and over again until it succeeds at the point of error. It just ignores it and moves on to the next. We need something that runs that scenario until it succeeds at the point of error because that data is needed first thing in the morning, otherwise the scenario is useless.

Break seems to retry and rerun the scenario with its Flow Control and you’re able to choose how many cycles until it succeeds? Unless I’m completely misunderstanding the module, which is possible since I am by no means a Make expert.

No there’s nothing built into make that will rerun at the point of error. The scenario when it encounters a warning will rerun based on the number of times you configure on the break module though.

If you want register for our TechTalk this coming Monday. We will talk errors for an hour or so.

But truly if you’re getting these errors all the time you’re exceeding some sort of designed threshold and it’s time to rethink why.


Seems they’re working on releasing a Retry module and their 2 retry workarounds for now:

The Break seems to run as a success as an error-handler, but pulls no data? No idea.

Cannot for the life of me figure out the 2nd method using the Repeater into my current scenario using Watch Events.

Thank you for the invite.

You can put more modules before the break module to handle other modules on the error route.

1 Like

@CLN3C here’s our Make Hero program if you want to try it Hero - NewPath Consulting and we can work out a few options:

  1. Use free Zapier to grab the data via web hooks or via Excel sheets
  2. Shuttle it to 1 Make scenario (rather than one for each customer). That way the first module is NOT Microsoft 365 Watch Events module.

You will also want to ask Make support why the watch event app doesn’t reprocess the original event that created the error if that happens. When it runs again it should process any outstanding events that have not yet been processed.

1 Like

I want to express my extreme gratitude and thank you and everyone who gave their valuable time and effort to try to resolve my 503 error. That was incredibly insightful, and I feel extremely grateful.

Thank you