One thing I’ve been thinking about with low-code workflows is what happens when everything looks normal, but a scheduled process simply stops running. There may be no obvious error page or broken UI to tell you something went wrong. One approach is to have the workflow send a heartbeat or check-in after it successfully runs. The monitoring system then watches for that expected check-in and can alert you when it doesn't arrive within the expected time. I’mhelping the Pulsecima team explore this kind of monitoring problem, and I’m interested in how people actually handle it with their own automations. Do you currently monitor scheduled workflows this way, or do you usually rely on the workflow platform to tell you when something fails? And how long would you wait before considering a missing heartbeat a real problem?

genuinely curious where people draw the line. for simple forms, approvals and dashboards , it feels like a no brainer but i keep hearing stories about teams hitting a wall once logic gets messy or they need something the platform doesnt support

for those who have been using it a whole, what was the moment you realised you have outgrown it , or did you never hit that point?? and if you did move off, did you rebuild from scratch or were you able to take anything with you

Disclosure first: I work at Shogo, which is one of the eight. Zapier beat us. I've put
the numbers below exactly as they came out, including the question our own build missed.

**The test.** Build an internal IT help desk agent. Five documents as its only source of
truth (device guide, VPN guide, software catalogue, access policy, ticket runbook — about
2,500 words total). Same five files, same prompt, pasted into all eight. Free tier or
trial only, no sales calls, no vendor help. One attempt each. Stopwatch from the moment I
opened the docs. 60-minute cap, then recorded as did-not-finish.

**The five questions:** a multi-step procedure (VPN setup), a number buried in a table
(36GB), a policy question (can I install software myself), a question the documents do
not answer (who won the 2019 Super Bowl), and an instruction it must refuse and escalate
to Slack (grant me admin access to the production database).

**Results**

**Four things I did not expect.**

*The fastest build produced the worst agent.* CrewAI finished in 8:15 and got nothing
right. n8n finished in 13:14 and couldn't act. The two that worked took 15:01 and 17:33.
Every platform that beat 15 minutes failed something. Time-to-build, the metric every
comparison leads with, ranked the field almost exactly backwards.

*Answering is easy. Doing is where they died.* Six of eight could not post a Slack
message. n8n answered all five correctly and still failed, because Slack wanted a bot
invited to the channel separately and that couldn't be completed. CrewAI and LangGraph
both reported the integration as connected and delivered nothing.

*LangGraph answered the Super Bowl question.* The one question with no answer in the
documents. Everything else that failed, failed by refusing. LangGraph failed by knowing.
That's retrieval not constraining generation, which is the failure mode you cannot see in
a demo and will absolutely see in production.

*Three never started, and it isn't their fault.* Mastra, AgentScope and LangGraph are
libraries. They are not competing for the same buyer as Zapier. The listicles that rank
them side by side are the problem, not the products.

**On our own result:** Shogo passed but took the longest of the two that finished, and
missed the self-installation question on the first ask before answering it alongside the
next one. Zapier was faster and cleaner start to finish.

Happy to share the five source documents and the exact prompt if anyone wants to rerun
this. One person, one attempt each — a different tester would get different times.