What this means (non-technical) If a workflow does not explicitly define a timezone, it uses the server’s default timezone. If the server timezone changes, the workflow’s execution time shifts with it. This can happen during migrations or infrastructure changes. What usually goes wrong After moving to a new server or environment: Scheduled workflows run hours earlier or later. Daily reports use the wrong date boundaries. Notifications are sent at unexpected times. Because not

What this means (non-technical) A cron expression controls when a scheduled workflow runs. If the expression is malformed or incorrectly structured, the workflow may run at the wrong time, or not at all. The schedule may look correct at a glance, but behave differently in practice. What usually goes wrong Common issues include: Using the wrong number of fields. Misunderstanding day-of-week numbering. Setting impossible date combinations. Typing special characters incorrectly.

What this means (non-technical) AI nodes can fail for many reasons, such as rate limits, service outages, or invalid responses. If there is no retry logic or failure handling configured, a single AI error can stop the entire workflow. There is no safety net. What usually goes wrong When an AI call fails: The workflow crashes immediately. Any work done before the AI step is lost. No fallback message is sent to users. Errors may only appear in execution history. Because AI serv

What this means (non-technical) A global error workflow is a dedicated workflow that catches failures from other workflows. If none is configured, errors may only appear in execution history. There is no centralized alert or logging process. What usually goes wrong Without a global error handler: Failures go unnoticed. Critical automations stop silently. Problems are discovered only after someone reports them. Debugging becomes reactive instead of proactive. You may believe e

What this means (non-technical) An IF node has two outputs: true and false. If only one branch is connected and the other is left unconnected, items sent to the unconnected branch are silently dropped. There is no automatic warning. What usually goes wrong If your condition does not match all items: Some items disappear. Processing becomes incomplete. Results appear inconsistent. Because there is no error, it may take time before anyone notices missing data. This often happen

What this means (non-technical) A Switch node routes items based on defined conditions. If an item does not match any condition and there is no fallback route, that item is dropped silently. No error. No warning. What usually goes wrong When upstream data changes: New values are introduced. Formats shift slightly. Unexpected edge cases appear. Items that don’t match existing routes simply disappear from the workflow. You may only discover the problem much later, when data cou

What this means (non-technical) This occurs when JSON.parse() is used in a Code node without handling possible errors. If the input string is not valid JSON, JSON.parse() throws an exception. This immediately crashes the workflow. What usually goes wrong APIs sometimes return: Error messages instead of JSON. Empty responses. Truncated or malformed data. When JSON.parse() encounters invalid input: The workflow stops entirely. All items being processed are lost. The error messa

What this means (non-technical) A merge deadlock occurs when a Merge node is configured to wait for multiple branches, but one branch never sends data. The Merge node keeps waiting forever. This usually happens when conditional logic prevents one branch from executing. What usually goes wrong If one branch produces no output: The Merge node never completes. The workflow appears “running” but makes no progress. No clear error is shown. Executions accumulate in a stuck state. T

What this means (non-technical) A fragile external call is an API request or external service call that has no retry or error-handling configuration. If the service fails once, the entire workflow fails immediately. There is no buffer for temporary issues. What usually goes wrong External services occasionally return errors due to: Short network interruptions. Temporary outages. Rate limiting. Timeouts. Without retry or controlled failure handling: The entire workflow stops.