“Problem running workflow
The workflow has issues and cannot be executed for that reason. Please fix them first.”
No logs
To add on…
Look closely at your workflow canvas. Nodes with validation errors typically display a small red exclamation mark or a warning icon in the top-right corner of the node box. This is the fastest way to pinpoint the culprit.
Ensure every node requiring authentication has a credential selected. If you recently migrated the workflow from another instance or updated n8n, the credential IDs might be missing or mismatched, even if the dropdown looks like it has a value. Re-select the credential to be sure.
Hi @fakihi, welcome to the community! 
So, the message “The workflow has issues and cannot be executed for that reason” isn’t a runtime error, which is exactly why you’re seeing nothing in the logs. n8n runs a validation check before it starts an execution, and if any node fails that check the run never actually begins so there’s no execution data to report on.
Most common causes are:
1. Look for warning icons on the nodes. Scan the canvas carefully. Nodes with validation issues show a small red exclamation mark or warning icon in the top-right corner. That’s usually the fastest way to find the culprit.
2. Check credentials on every node. Make sure each node that requires authentication has a credential properly selected. Even if the dropdown looks populated, the credential ID can be missing or mismatched. This is especially common after migrating from another instance. Try re-selecting the credential on any node that uses one.
4. Check for disconnected nodes. A node sitting on the canvas without being connected to the main flow can sometimes trigger validation warnings.
One separate note: you’re on 1.123.67, which is a fair way behind the current release. I don’t think it’s related to this particular error, but upgrading when you get the chance will pick up a lot of fixes and improvements in the meantime.
If none of those turn it up, let me know which node shows the warning icon and what the tooltip says. Happy to dig in further from there.
Best,
Urška
Urska’s answer is the right first stop — “The workflow has issues and cannot be executed” is the pre-flight validation, and the warning icon on the canvas is usually the fastest way to the culprit.
One thing worth adding, because it bites specifically on scheduled workflows: this failure mode is invisible to your error handling.
An Error Workflow only fires when an execution fails. As noted above, validation runs before the execution starts — so there is no execution. Nothing fails, nothing is logged, and nothing triggers. The schedule just quietly stops producing, and the Executions list shows no failures, because it shows nothing at all. If you had not gone looking, it could sit like that for weeks.
So once the node is fixed, it is worth watching for absence rather than for errors. The cheapest version is a second scheduled workflow that asks the API whether the first one has produced a successful execution recently:
GET /api/v1/executions?workflowId=YOUR_ID&status=success&limit=1
Compare the newest startedAt against the interval you expect, and alert if it is older than about two cycles. That also covers a few neighbours that produce no error for an Error Workflow to catch: a workflow left deactivated, a schedule that never re-armed, and the instance being down at trigger time.
Worth asking which of your scheduled workflows you would actually notice stopping. It is usually fewer than people expect.
Disclosure: this reply was drafted with AI assistance. The point about an Error Workflow never firing follows from the pre-execution validation behaviour described earlier in this thread — if that does not match what you are seeing on your instance, say so and I will correct it.
Updating fixed the issue. Thanks!
One cause that’s easy to miss beyond the credential/warning-icon checks above: an expression that references a node which was renamed or deleted upstream. Something like {{ $node["HTTP Request"].json.id }} will fail validation the moment “HTTP Request” no longer exists under that exact name — and the offending node isn’t always the one you’d expect, so the red icon can be easy to overlook if the node is collapsed or off-screen.
Fastest way to pin it down: open the workflow’s ... menu → Download, and search the exported JSON for any $node[ / $items( references, then confirm each referenced name still matches a node on the canvas. An empty/blank interval on the Schedule Trigger itself will also trip the same “fix them first” gate.
And yes — 1.123.67 is worth updating regardless; a few validation edge-cases have been fixed since then.