Tl;DR
As of 2025, Monday.com runs on a rock-solid tech stack — Redux, Pusher.js, and more — enabling real-time automatic updates. But one key thing is still missing from its automation engine: cycle detection.
Key take-aways:
- Users can accidentally sabotage themselves with loops and burn their 25k+ executions
- Monday protects itself with throttling, but users are still exposed
- A simple
(A → B + B → A)check could solve this
A Peek at the Technical Solution
I’ve published a deeper technical post on how to detect cycles in JS-based multigraphs using Graphlib in Toward Cycle Detection in AI Automation Workflows.
Spoiler: as of 2025, there's still no native JS library that handles edge-aware cycle detection for multigraphs.
The story
The villain of the story resides in automations (available in the free plan) - where it's possible to create something that every developer loves - an infinite loop ∞.
Fortunately, Monday uses a time-based throttling mechanism. Each automation tick executes with a delay (~1–2s between updates). This prevents instant overload, but still means that a board with 1,000 items could experience severe lag if each item is being mutated continuously by an automation loop.
As seen in the execution history, each automation runs with a ~1–2 second interval. That is a good indication that it likely doesn't hit a complex server-side event bus — but executes the mutations locally, much like user actions.
That's something that Monday does very well - board items are extremely mutable, and merges of user actions happen instantly.
Yet, I think it's a safe bet to say that creating 1k items and making them tick individually for infinite time is definitely gonna have a negative effect - considering the changes are streamed per item and not in batch.
That's one of the system design decisions made in Monday, that seems to make sense when you look at the platform on a high level. It'd hard to batch items for execution when each can have transitive states.
That said, under the right conditions, a form of conditional batching becomes not only safe — but strategically valuable. I explore this in more detail in Automation at Scale: Why One Item at a Time Is Breaking Down, including how platforms can batch intelligently without sacrificing correctness.
Fortunately Monday.com comes with a simple power plug here - after 25k automation runs on Pro Plan - it's game over. No more runs.
It’s generous — Monday’s Pro plan allows up to 25,000 automation runs — far more than ClickUp’s 1k–5k limit or Zapier’s pricing tier for 20k Zaps (~$160/month). Still - this rate is vulnerable if users unknowingly burn through it with a loop.
Zapier’s pricing gets expensive fast — 20k Zaps costs over $160/month.
As demonstrated, there is a real 'war' for computing power in the automation builder platform world.
Implications for Customers
We established that Monday does a pretty good job in offering high automation execution rates, and limiting the interval in which they are fired which protects customers from instant execution depletion.
Yet, there is still a scenario where customers may unwillingly sabotage their own account.
Imagine a case where you have 30-50 automations (which actually happens according to Community blogs)
Say you delete one automation — thinking you’re cleaning up. But that deletion breaks a subtle dependency, and now 1,000 items on your board start ticking in a self-referencing loop. Your 25k monthly automation limit? Gone in minutes. 😬
A Simple UX Proposal: Detecting Cycles Visually
From UX/UI perspective it sounds simple:
when (A → B) + (B → A) ⇒ show warning / prevent save.
Monday already uses toast messages to warn users — so surfacing loop conflicts visually would fit their existing UI patterns. You could even highlight conflicting automations and gray out the "Save" button until resolved.
Here this may just not be enough - you might want to highlight the conflicting automations and find the last conflicting cycle and freeze the recipe that is causing it:
(Slightly more verbose sketch of loop prevention)
Now, this isn't to say that Monday has to explicitly block infinite loops - but they can at least warn User of the risk involved.
In fact some companies went as far as to block repetitive cycles upon hitting certain execution threshold, but that's a scenario that should usually be avoided (it can interrupt a crucial user network).
Potential Trial-Based Synthetic Load Attack
Let’s take this a step further: imagine someone spins up trial accounts and sets up infinite loops across thousands of items. Since automations are server-side operations, no active user input is needed — just a ticking time bomb that eats through 25k executions, spiking load.
As Monday scales and raises rate limits to stay competitive, it may also become more vulnerable to synthetic load attacks — especially from trial users exploiting infinite loops.
When analysing logs it may also be relatively hard to find actors who have crossed a certain threshold of operations if items would be removed occasionally.
Obviously for this kind of stress test that would mean an enormous inflation of per item logs (I generated around 120 ticks in 1-2 minutes):
As mentioned on monday.com technical blog - there is occasionally an issue with noisy customers stressing the shared traffic bandwidth. Silent infinite loops like this are one of the things that may be harder to detect in the huge lake of customer data, and can silently generate traffic costs.
So at this scale we occasionally observed individual users generating 20-30% of the overall system load! We needed a way to quickly (in a matter of minutes) discover such individuals and take some precautions. This phenomenon is often called noisy neighbor and it doesn’t only apply to cloud hardware being overutilized by other tenants. For the time being, we simply ban problematic user accounts for a few minutes.
Conclusion
Monday.com does a great job balancing speed — but invisible automation loops remain a real risk. Execution throttling and quota caps help protect the system, but users are still vulnerable to accidental sabotage.
A simple cycle detector — even just a UI warning — could go a long way in protecting both users and the platform from runaway automations.
Top comments (0)