AI node blocks synchronous webhook response path — Webhook senders have hard response timeouts: Slack 3 s, Shopify 5 s, GitHub 10 s, Stripe 30 s. AI calls typically take 10–60 seconds. When the sender times out, it marks the delivery failed and retries — the workflow processes the same event twice, potentially creating duplicate records, emails, or actions.
Scheduled workflow fetches all records with no incremental filter — In development with small datasets, this is imperceptible. As data accumulates in production, each execution takes longer, uses more memory, costs more in API calls, and eventually hits provider rate limits — all without any change to the workflow.
Side-effect node has no audit trail — If this action is disputed, replayed, or causes a data inconsistency, there is no structured record of what was sent, when, and with what data. Debugging requires cross-referencing n8n execution history with the external system's own logs.
| Check | Description | Status |
|---|---|---|
| Failure Alerting | Failures silent — only visible in execution log | Missing |
| Retry on Failure | Transient failures cause permanent stops | Present |
| Request Timeouts | Slow providers can block execution indefinitely 1 / 12 external nodes have timeout | Partial |
| Duplicate Prevention | Retry on write events creates duplicate records | Missing |
| Empty Response Handling | Zero-result lookups break downstream logic | Present |
| AI Output Limits | Output cost and parsing risk unbounded | Present |
| AI Output Format | Free-form output will break downstream parsers 1 of 8 AI nodes lack structured output | Partial |
| Activity Logging | Side effects unlogged 3 of 4 write nodes missing audit log | Partial |
| Write Deduplication | Webhook replays may create duplicate records | Missing |
Run this analysis on your own workflows
- Production Incident Detector
- Supervisor Orchestrator
Webhook senders have hard response timeouts: Slack 3 s, Shopify 5 s, GitHub 10 s, Stripe 30 s. AI calls typically take 10–60 seconds. When the sender times out, it marks the delivery failed and retries — the workflow processes the same event twice, potentially creating duplicate records, emails, or actions.
Respond to the webhook immediately with a 202 Accepted using a Respond to Webhook node placed before the AI work. Move the AI processing to continue asynchronously after the response.
- Supervisor Orchestrator
- Hardcore Developer
- Risk Evaluator
A single slow external call can block the entire workflow execution. At high trigger frequency, accumulated stuck executions can exhaust the n8n execution queue.
Set a timeout under the node's Additional Options. A value of 10,000–30,000 ms (10–30 seconds) is a reasonable starting point for most APIs; adjust based on the provider's documented SLA.
- Supervisor Orchestrator
- Hardcore Developer
- Risk Evaluator
Operators cannot tell from external signals that a run failed. Silent failures go undetected until a downstream system shows missing data or a user reports a problem.
Connect a dedicated Error Workflow in workflow settings, or add a per-node onError: "continueErrorOutput" path that sends an alert via Slack, email, or a logging service.
- Send to Devlogs channel
These expressions work reliably against test data where all fields are present. In production, fields may be absent, null, or differently typed — causing a runtime error or silent null propagation at the point of the expression.
- In `content`, change {{ $json.discord_message }} to {{ $json?.discord_message }}.
- Send to DevGroup
These expressions work reliably against test data where all fields are present. In production, fields may be absent, null, or differently typed — causing a runtime error or silent null propagation at the point of the expression.
- In `text`, change {{ $json.telegram_message }} to {{ $json?.telegram_message }}.
- Send to Team
These expressions work reliably against test data where all fields are present. In production, fields may be absent, null, or differently typed — causing a runtime error or silent null propagation at the point of the expression.
- In `text`, change {{ $json.slack_message }} to {{ $json?.slack_message }}.
- Send to Director
These expressions work reliably against test data where all fields are present. In production, fields may be absent, null, or differently typed — causing a runtime error or silent null propagation at the point of the expression.
- In `subject`, change {{ $json.gmail_subject }} to {{ $json?.gmail_subject }}.
- In `message`, change {{ $json.gmail_html }} to {{ $json?.gmail_html }}.
- Regular Scanner: Everyday at 9am
- Send to Director
In development with small datasets, this is imperceptible. As data accumulates in production, each execution takes longer, uses more memory, costs more in API calls, and eventually hits provider rate limits — all without any change to the workflow.
Add a time-based filter parameter using $now minus the trigger interval (e.g., updatedAfter: {{ DateTime.now().minus({ hours: 1 }).toISO() }}). Alternatively, track the last-processed timestamp in a database or workflow static data and filter to records newer than that point.
- Send to DevGroup
- Send to Team
- Send to Director
If this action is disputed, replayed, or causes a data inconsistency, there is no structured record of what was sent, when, and with what data. Debugging requires cross-referencing n8n execution history with the external system's own logs.
After the write node, add a step that records the key fields of the action to a log — a Google Sheet row append, a database insert to an audit table, or a Slack message to a dedicated ops channel. Include: timestamp, action type, affected ID, and result.
Currently covers AI/LLM nodes. Non-AI API costs will be added in a future update.
- Regular Scanner: Everyday at 9am
full dataset fetched on every run
Add a time-based filter parameter using $now minus the trigger interval (e.g., updatedAfter: {{ DateTime.now().minus({ hours: 1 }).toISO() }}). Alternatively, track the last-processed timestamp in a database or workflow static data and filter to records newer than that point.
- Supervisor Orchestrator
- Hardcore Developer
- Risk Evaluator
no max iterations set
Set maxIterations to 10–20 for most agentic tasks. Monitor actual iteration counts in execution history and adjust up if legitimate tasks are being cut short.
| # | Issue title | Issue description | Affected nodes | |||
|---|---|---|---|---|---|---|
| 1 | Reliability | AI node blocks synchronous webhook response path | Node "Production Incident Detector" executes in the synchronous response path of the webhook trigger. The webhook trigger's | Production Incident Detector, Supervisor Orchestrator | High | 85% |
| 2 | Reliability | External call with no timeout configured | Node "Supervisor Orchestrator" makes an external call with no timeout parameter set. The n8n execution will wait indefinitely if the provider is slow or unresponsive. | Supervisor Orchestrator, Hardcore Developer, Risk Evaluator, PR & Status Manager, llama-3.3-70b, gemini-2.5-flash-lite, gemma-4-31b, openai/gpt-oss-20b, Send to DevGroup, Send to Team, Send to Director | High | 90% |
| 3 | Security | Finding: webhook no auth | authentication: absent. path: short custom path "__KIPNAI_SAN__WEBHOOK_URL__c6cvjFw9__" (enumerable). downstream write node(s): "Send to Devlogs channel", "Send to Director", "Send to Team", "Send to DevGroup" | Production Incident Detector, Send to Devlogs channel, Send to Director, Send to Team, Send to DevGroup | High | 90% |
| 4 | Reliability | No error handler or failure notification path | Workflow has 18 high-risk nodes (external calls or writes) with no configured error workflow and no inline notification path. If a production execution fails, the failure only appears in execution history. | Supervisor Orchestrator, Hardcore Developer, Risk Evaluator, PR & Status Manager, Aggregator Layer, Automated Prompt, Data Preparer, llama-3.3-70b, gemini-2.5-flash-lite, gemma-4-31b, openai/gpt-oss-20b, Send to Devlogs channel, Send to DevGroup, Send to Team, Send to Director, Debugging Memory, Status Memory, Evaluation Memory | High | 85% |
| 5 | Cost Risk | AI agent has no iteration limit | Agent node "Supervisor Orchestrator" has no | Supervisor Orchestrator | Medium | 85% |
| 6 | Cost Risk | AI agent has no iteration limit | Agent node "Hardcore Developer" has no | Hardcore Developer | Medium | 85% |
| 7 | Cost Risk | AI agent has no iteration limit | Agent node "Risk Evaluator" has no | Risk Evaluator | Medium | 85% |
| 8 | Cost Risk | AI agent has no iteration limit | Agent node "PR & Status Manager" has no | PR & Status Manager | Medium | 85% |
| 9 | Reliability | AI output drives downstream logic without a structured format | Node "Supervisor Orchestrator" produces free-form text output that flows into downstream logic with no Output Parser or JSON mode configured. | Supervisor Orchestrator | Medium | 75% |
| 10 | Reliability | Fragile expression — likely to fail when production data shape differs from test data | Node "Supervisor Orchestrator" contains expression(s) with risky patterns that assume fields are always present. | Supervisor Orchestrator | Medium | 75% |
| 11 | Reliability | Fragile expression — likely to fail when production data shape differs from test data | Node "Send to Devlogs channel" contains expression(s) with risky patterns that assume fields are always present. | Send to Devlogs channel | Medium | 75% |
| 12 | Reliability | Fragile expression — likely to fail when production data shape differs from test data | Node "Send to DevGroup" contains expression(s) with risky patterns that assume fields are always present. | Send to DevGroup | Medium | 75% |
| 13 | Reliability | Fragile expression — likely to fail when production data shape differs from test data | Node "Send to Team" contains expression(s) with risky patterns that assume fields are always present. | Send to Team | Medium | 75% |
| 14 | Reliability | Fragile expression — likely to fail when production data shape differs from test data | Node "Send to Director" contains expression(s) with risky patterns that assume fields are always present. | Send to Director | Medium | 75% |
| 15 | Cost Risk | Scheduled workflow fetches all records with no incremental filter | Node "Send to Director" fetches all records with no time-based or incremental filter. Every execution retrieves the full dataset. | Regular Scanner: Everyday at 9am, Send to Director | Medium | 70% |
| 16 | Observability | Side-effect node has no audit trail | Node "Send to DevGroup" performs a write node: "send to devgroup" (sideeffect: external_write) operation with no logging or audit trail detected downstream. | Send to DevGroup | Medium | 70% |
| 17 | Observability | Side-effect node has no audit trail | Node "Send to Team" performs a write node: "send to team" (sideeffect: external_write) operation with no logging or audit trail detected downstream. | Send to Team | Medium | 70% |
| 18 | Observability | Side-effect node has no audit trail | Node "Send to Director" performs a write node: "send to director" (sideeffect: external_write) operation with no logging or audit trail detected downstream. | Send to Director | Medium | 70% |
| 19 | Reliability | Webhook trigger feeds write operation without unique-key protection | The webhook trigger feeds node "Production Incident Detector" without a visible unique key constraint or deduplication step. No ID field parameter was detected in the write node configuration. | Production Incident Detector, Send to Devlogs channel | Medium | 65% |
| 20 | Reliability | Webhook trigger feeds write operation without unique-key protection | The webhook trigger feeds node "Production Incident Detector" without a visible unique key constraint or deduplication step. No ID field parameter was detected in the write node configuration. | Production Incident Detector, Send to Director | Medium | 65% |
| 21 | Reliability | Webhook trigger feeds write operation without unique-key protection | The webhook trigger feeds node "Production Incident Detector" without a visible unique key constraint or deduplication step. No ID field parameter was detected in the write node configuration. | Production Incident Detector, Send to Team | Medium | 65% |
| 22 | Reliability | Webhook trigger feeds write operation without unique-key protection | The webhook trigger feeds node "Production Incident Detector" without a visible unique key constraint or deduplication step. No ID field parameter was detected in the write node configuration. | Production Incident Detector, Send to DevGroup | Medium | 65% |
| 23 | Reliability | Fragile expression — likely to fail when production data shape differs from test data | Node "Create an issue" contains expression(s) with risky patterns that assume fields are always present. | Create an issue | Low | 75% |
| 24 | Reliability | Finding: external without retry | Node "Supervisor Orchestrator" (@n8n/n8n-nodes-langchain.agent) is a read-only external call with no retry configured.. sideEffect: read_only, role: ai_agent. Read-only calls are typically safe to retry; enabling retryOnFail improves resilience to transient failures. | Supervisor Orchestrator | Info | 70% |
| 25 | Reliability | Finding: external without retry | Node "Hardcore Developer" (@n8n/n8n-nodes-langchain.agentTool) is a read-only external call with no retry configured.. sideEffect: read_only, role: ai_agent. Read-only calls are typically safe to retry; enabling retryOnFail improves resilience to transient failures. | Hardcore Developer | Info | 70% |
| 26 | Reliability | Finding: external without retry | Node "Risk Evaluator" (@n8n/n8n-nodes-langchain.agentTool) is a read-only external call with no retry configured.. sideEffect: read_only, role: ai_agent. Read-only calls are typically safe to retry; enabling retryOnFail improves resilience to transient failures. | Risk Evaluator | Info | 70% |
| 27 | Reliability | Finding: external without retry | Node "PR & Status Manager" (@n8n/n8n-nodes-langchain.agentTool) is a read-only external call with no retry configured.. sideEffect: read_only, role: ai_agent. Read-only calls are typically safe to retry; enabling retryOnFail improves resilience to transient failures. | PR & Status Manager | Info | 70% |
| 28 | Reliability | Finding: external without retry | Node "llama-3.3-70b" (@n8n/n8n-nodes-langchain.lmChatGroq) is a read-only external call with no retry configured.. sideEffect: read_only, role: ai_model_call. Read-only calls are typically safe to retry; enabling retryOnFail improves resilience to transient failures. | llama-3.3-70b | Info | 70% |
| 29 | Reliability | Finding: external without retry | Node "gemini-2.5-flash-lite" (@n8n/n8n-nodes-langchain.lmChatOpenRouter) is a read-only external call with no retry configured.. sideEffect: read_only, role: ai_model_call. Read-only calls are typically safe to retry; enabling retryOnFail improves resilience to transient failures. | gemini-2.5-flash-lite | Info | 70% |
| 30 | Reliability | Finding: external without retry | Node "gemma-4-31b" (@n8n/n8n-nodes-langchain.lmChatOpenRouter) is a read-only external call with no retry configured.. sideEffect: read_only, role: ai_model_call. Read-only calls are typically safe to retry; enabling retryOnFail improves resilience to transient failures. | gemma-4-31b | Info | 70% |
| 31 | Reliability | Finding: external without retry | Node "openai/gpt-oss-20b" (@n8n/n8n-nodes-langchain.lmChatOpenRouter) is a read-only external call with no retry configured.. sideEffect: read_only, role: ai_model_call. Read-only calls are typically safe to retry; enabling retryOnFail improves resilience to transient failures. | openai/gpt-oss-20b | Info | 70% |