N8n Cloud: Production webhooks return 500 error and Schedule Trigger does not create executions

[Luis_Gustavo_Araujo]

Hello,

I’m facing an issue that appears to be related to the n8n Cloud environment/workspace.

I’m experiencing two different behaviors happening in the same workspace:

1. Production webhooks fail before creating an execution.
2. Published Schedule Triggers are also not creating automatic executions.

PRODUCTION WEBHOOK

I tested with a new workflow containing only:

Webhook

• Method: POST
• Authentication: None
• Respond: Immediately

The test URL works normally:

/webhook-test/…

However, the production URL:

/webhook/…

returns HTTP 500 with:

{
“code”: 0,
“message”: “There was a problem executing the workflow”
}

Most importantly, no execution is created in the workflow history.

I’ve already tested:

• brand new workflow;
• new Webhook node;
• new path;
• published workflow;
• no nodes connected after the Webhook;
• authentication disabled;
• manual call to the production URL.

The test URL works normally, but the production URL returns 500 and doesn’t create an execution.

SCHEDULE TRIGGER

As an alternative to the Webhook, I changed an automation to use Schedule Trigger.

I tested with:

Schedule Trigger

• interval: minutes;
• every 5 minutes;
• also tested every 1 minute;
• published workflow.

The workflow is configured to save:

• Production executions;
• Test executions.

Even so, after publishing and waiting several minutes, no automatic execution appears.

Manual executions work normally.

BEHAVIOR SUMMARY

• Manual execution: works.
• Webhook Test URL: works.
• Webhook Production URL: returns HTTP 500.
• Production webhook: doesn’t create any execution.
• Published Schedule Trigger: doesn’t create any execution.
• Production executions are configured to be saved.
• No execution with error exists.
• No execution in queue.
• Simply no production execution is started.

For this reason, it appears the issue occurs before the workflow starts executing nodes.

This same workspace was previously executing production workflows normally, so this is not a new configuration.

Has anyone encountered this behavior in n8n Cloud?

Could this be an issue with trigger registration, execution worker, scheduler, or some internal workspace configuration?

Thank you.

Describe the problem/error/question

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

• n8n version:
• Database (default: SQLite):
• n8n EXECUTIONS_PROCESS setting (default: own, main):
• Running n8n via (Docker, npm, n8n cloud, desktop app):
• Operating system:

[n8n]

Hey @Luis_Gustavo_Araujo, while you wait for a response, here are some things that might help:

Suggested resources

Automatically matched to your question.

Docs:

• Changelog

Forum:

• My Schedule Trigger on n8n Cloud has stopped firing automatically — no scheduled executions appear in the Execution log at all — but manually running the workflow works perfectly every time
• Schedule Trigger silently stops firing after several days (Kubernetes + queue mode)
• Forminator webhook - failed to process request

@Anshul_Namdev, @kjooleng - you’ve helped with similar issues before, can you take a look?

Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.

[Deepankar]

Hey @Luis_Gustavo_Araujo

A suspicion of a workspace issue makes sense, since both the Production Webhook and Schedule Trigger are failing, while manual tests work. But this 500 error is generic and doesn’t confirm which component is failing.

I’d start by restarting the workspace from the Cloud dashboard, using the “Restart workspace” option, and repeat both tests after it comes back up. What version of n8n are you running? If it’s still the same after restarting, send to help@n8n.io the workspace URL, the IDs of those workflows, and the time of a call that returned 500, including your timezone.

[operantsolo]

Since both the production webhook and the schedule fail and nothing even gets logged, it sounds like production executions aren’t starting on your workspace at all.

Worth ruling out: check whether your plan’s monthly execution limit has been reached (test runs often keep working while production ones are refused); unpublish and republish one workflow after a restart, then hit the production URL once; check Executions filtered to All workflows.

If nothing changes, email support with the workspace URL, workflow IDs and the exact time of a 500.

[Shital_Katre]

Hi @Luis_Gustavo_Araujo,

This specific behavior—where the Test URL triggers perfectly but the Production URL returns a generic HTTP 500 with “There was a problem executing the workflow” without logging anything in the execution history—is a classic symptom of an infrastructure/worker starvation issue on n8n Cloud, rather than a workflow node design error.

Since both the published Production Webhook and the background Schedule Trigger fail to spawn an execution entry, here are the exact infrastructure blockages that usually cause this:

1. Database Lock / SQLite/Postgres Write Block: When a production webhook hits, n8n attempts to write a fresh record into the execution_entity table before executing Node 1. If the workspace database is currently locked due to transactional bloat, heavy logging, or a stalled worker process, the initialization fails silently at the core framework level and drops the event with a 500 response.
2. Worker Registration Drop: In multi-tenant environments like n8n Cloud, if the internal scheduler/redis cluster loses its active routing lease to your specific container workspace, the published triggers (Schedule/Webhook) fail to register events into the active execution loop, while manual button clicks (which bypass the worker queue) continue to run fine.

What you should do right now:

• The Cloud Force Reset: As @Deepankar suggested, use the n8n Cloud dashboard to completely stop and restart the instance. This terminates any zombie connections or database locks hanging in the background.
• The “Save Executions” Toggle Check: Double-check if your workspace storage is maxed out. If the disk quota allocated to your Cloud plan is 100% full, the database will refuse the initial execution write-state, causing an instant HTTP 500 on production traffic.

If you are running mission-critical enterprise webhooks and continue to face these Cloud environment locks, I highly recommend transitioning to a self-hosted Docker Compose architecture backed by dedicated PostgreSQL transaction ledgers and Redis DLQ setups to ensure zero data drops.

Let me know if the full cloud workspace restart brings the workers back alive!