# Troubleshooting and FAQ | Docs - nodulz Source: https://nodulz.com/docs/troubleshooting Language: en Start with a specific execution. Record its status, the first failed node, its message and the data it received. Trigger delivery problems and processing problems have different starting points. ## No execution appears 1. Check that the workflow is published and that trigger changes have been published again. 2. For a webhook, use the URL displayed by the node, the configured HTTP method and authentication. Check the response received by the caller. 3. For a provider event, check that the correct event is enabled and that the service can reach the instance. Inspect its delivery history if available. 4. For a schedule, check the mode, days and timezone on the [node page](/docs/nodes/schedule). A simulated editor payload does not test these delivery conditions. If the workflow processes that payload correctly, focus on the trigger and external connection. ## The webhook responds but a step failed Immediate response mode replies before processing finishes. Find the execution in history and check its final status. If the caller needs the business result, configure a response mode that waits for that result; see [Webhook](/docs/nodes/webhook) and [Webhook response](/docs/nodes/webhook_response). ## An expression is empty or null Check in this order: 1. **Input shape**: `input.email` for a simple manual payload, often `input.body.email` for a JSON webhook. 2. **Technical name**: use the name offered by mapping, such as `nodes.http1`, rather than guessing a service name. 3. **Actual output**: with **Body only**, `nodes.http1.body.id` may become `nodes.http1.id`. 4. **Executed branch**: a node on a branch that was not taken supplies no output. 5. **Test scope**: an isolated test does not prove upstream steps ran with the same data. Run the relevant chain again. Check expression diagnostics in logs and the [data guide](/docs/expressions). An optional fallback with `??` can help; it does not replace required field validation. ## A node receives text instead of an object or number In Edit fields, `120` is text and `{{ 120 }}` is a number. A standalone expression can preserve an object or list; combining text and an expression produces a string. Variables created by this node are textual. Use its output `nodes.set1.` to preserve the type. If the source really contains a JSON string, use [Parse JSON](/docs/nodes/parse_json) and its `parsed` property. ## A condition takes the wrong branch Open the [IF](/docs/nodes/if) output: `conditions` shows the value read, operator, comparison value and result for each condition. `result` shows their final combination. Check the field path, case and spaces for text equality, and the **AND** or **OR** choice. The `gt`, `gte`, `lt` and `lte` operators are numeric; an empty value is not proof of valid numeric input. Also check that connections use the correct **true** or **false** output. ## A loop processes only one batch or uses the wrong item Check that the source points to the intended list and that the repeated action starts from **Loop**, rather than **Done**. With `batchSize: 1`, the node exposes the current element in `item`. With larger batches, `item` can be a list. `input` remains the original input: read the [loop](/docs/nodes/loop_over_items) output for the current item. Test two distinct elements to catch an action that always reuses the first one. ## A credential is missing or access is denied Check the exact credential type required by the node and sharing with the workflow owner. SMTP and IMAP access, or PostgreSQL and pgvector access, are not interchangeable. If the credential is selected but the operation fails, record the service response. Authentication problems and insufficient permissions require different fixes. The [credential guide](/docs/credentials) gives the checking order. ## An HTTP request returns an error - **401 or 403**: check the authentication mode, selected access and resource permissions. - **404**: check the constructed URL, resource identifier and target environment. - **429**: check provider limits and reduce the request rate; an immediate retry loop may make the problem worse. - **5xx or timeout**: check service availability and any effects already produced before retrying a write. The [HTTP](/docs/nodes/http) node fails on non-2xx responses by default. To handle a status deliberately in an IF, disable **Fail on HTTP errors**, keep **Include status** enabled and disable **Body only**. Provide an explicit failure branch: technical node success then no longer means request success. ## An action ran twice Compare execution and event identifiers. Determine whether the provider delivered two events, you restarted manually, or a retry policy replayed an already completed step. Before another attempt, check the destination state. Use an idempotency key when the API supports one, or check whether processing already happened using a stable business identifier. The [execution guide](/docs/executions) explains retry scopes. ## An execution remains paused A pause may correspond to a planned wait or agent tool approval. Open the execution to inspect the request. For approval, review the action and arguments, then use **Approve and resume** or **Reject and resume** with an authorized account. Do not restart the entire workflow to answer an approval: that could repeat previous steps. See [Agent tool approval](/docs/executions#agent-tool-approval). ## An agent fails or answers without the expected data Check the selected model and credential, component ports and tool names. A tool mentioned in the prompt must also be connected and configured. Inspect the trace to see whether it was actually called. For turn or token limits, reduce the task and context first, then adjust the relevant limit. `maxTokens` bounds one call’s output; `maxTotalTokens` bounds this agent’s cumulative usage. A total budget requires the provider to return usage information. For document retrieval, inspect retrieved passages and check that questions and documents use the same embedding model and dimensions. The [workflow guide](/docs/workflows#agents-and-document-retrieval) separates indexing from questions. ## Prepare a support request Collect the instance name and version, incident time with timezone, execution identifier, node type, exact message and reproduction steps. Describe the expected result, actual result and whether the incident concerns a test or a real event. Attach a minimal anonymized example. Remove API keys, tokens, cookies, authentication headers and personal data from payloads, screenshots and logs. ## Explore further - [Features - nodulz](https://nodulz.com/product/overview) - [Node catalog - nodulz](https://nodulz.com/product/catalog) - [MCP server - nodulz](https://nodulz.com/product/mcp) - [Pricing - nodulz](https://nodulz.com/pricing) - [Use cases and workflow automation - nodulz](https://nodulz.com/use-cases) - [Choose what your workflows can do. - nodulz](https://nodulz.com/compare) - [Documentation - nodulz](https://nodulz.com/docs)