Why is my n8n instance slow, or stuck at 100% CPU?

If your instance is slow to start, CPU sits pinned near its limit, and logs fill with the same resume error over and over, you are almost certainly hitting a known n8n failure mode: a bloated execution history table.

That message is a symptom, not the root cause. The instance is spending its life managing history instead of running workflows.

What’s actually happening

Every time a workflow runs, n8n logs an execution record. Busy, frequently triggered workflows with no pruning make that table grow without a ceiling. Once it is large enough, n8n slows down just querying and managing history — not because your workflow logic is doing more work.

How to confirm it

If you have direct database access on your tier, run this against your instance Postgres database:

SELECT status, count(*) FROM execution_entity GROUP BY status ORDER BY 2 DESC;

A count in the hundreds of thousands (or more) is a strong signal. On Starter without direct DB access, open a support ticket and we will check for you.

The fix

Clearing the execution history table resolves it immediately:

TRUNCATE execution_entity RESTART IDENTITY CASCADE;

Then restart your n8n instance from the dashboard.

Preventing it from coming back

Enable execution data pruning in your workflow settings so old records clean up automatically instead of growing forever. If you are not sure how, ask us — this is exactly the kind of hosting-environment question that is in scope for support.

Written by the team that operates production n8n for customers. No invented case studies — just what we see when instances lock up.