Some n8n workflows have no execution history

Questions
1

Describe the problem/error/question

Hi there,

Some workflows don’t show any executions at all, although they are running sometimes hourly, yet nothing shows up. No filters set, no limitations on the UI.

Other workflows have a vivid execution history.

I’ve seen some posts about this issue, but most of them lead to no solution. The one proxy solution doesn’t apply in my case.

EXECUTIONS_DATA_MAX_AGE=168
EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000
EXECUTIONS_DATA_PRUNE=true

Configs were increased on the backend, yet the issue was not resolved. I’ve also checked and compared the Workflow settings of several workflows that have and don’t have executions. When I trigger them manually, executions exists and are logged.

I am beginning to conclude that someone used the test webhook URL instead of the production one, or maybe on the app side they set GET when it needs to be POST… But I need to be certain nothing else is wrong with n8n, the setup and the server.

If they were pruned, then they should at least show something in executions.

How is this possible? Did anyone have this issue before? How did you solve it?

Information on your n8n setup

  • n8n version: Version 2.8.3
  • Database (default: SQLite): PostgreSQL (Docker)
  • n8n EXECUTIONS_PROCESS setting (default: own, main): main
  • Running n8n via (Docker, npm, n8n cloud, desktop app): npm
  • Operating system: hosted on Ubuntu 24.04.4 LTS, UI on Chrome/Windows 10/11
3

Hi @dmtr

Your webhook URL theory is worth checking, but first look at something simpler: each workflow can override the global execution save settings.

Open an affected workflow → Settings (gear icon) → check “Save Successful Production Executions” and “Save Failed Production Executions.” If these are set to “Don’t Save” on the affected workflows, executions run fine but nothing gets recorded. The workflows that do show history likely have these set to “Default” or “Save.”

If those look fine, verify your webhook setup:

  1. Make sure the workflow is Published.

  2. Click the Webhook node and compare the Production URL against what the external system is calling. If it’s hitting the test URL, executions only work while the editor is open.

  3. Confirm the HTTP method matches (GET vs POST).

Start with the per-workflow save settings since that’s the most common cause of “it runs but no history.”

Let me know :crossed_fingers:

4

Hi @houda_ben,

Workflows are published.
Settings are enabled in the Workflows to save executions.
Awaiting feedback from the team on the URLs and HTTP methods used.

6

If the webhook URL (test webhook URL instead of the production one) or HTTP method is wrong, then you won’t see anything in the execution list at all.
Both issues will raise a client-side success message with a 404 status code, and nothing will be stored in the executions.

8

Quick thing worth ruling out before tweaking more config: are the workflows actually firing, or firing but not saving? Easy to tell apart - watch the n8n logs right when the schedule should run. Webhook hits show in stdout by default; for trigger fires you need N8N_LOG_LEVEL=debug. If you see the trigger fire but no row lands in execution_entity, it is a save-path issue. If you see nothing at all at the scheduled time, it is not firing in the first place.

Two common quiet culprits: the Active toggle being off (saved-but-inactive workflows look identical in the list, easy to miss across a few dozen), or global execution pruning trimming runs if you have a lot of hourly schedules. Worth ruling those out before anything fancier.

9

The issue has been identified. The issue is that the workflows have about 17k of executions daily. Increasing the default from 10k and 7 days to 50k and 30 days had little effect, since after 3 days pruning already started (50k limit). That caused lower volume executions to be pruned and high volume ones to remain. The 50k limit applies to all workflows, not individual ones.

Now I have 3 options. Which one do you recommend?

1.) Set execution limit to 250k, which probably will need a larger disk size to store this

2.) Disable size limit and only go on a time-based (30 day) pruning. This also will need a bigger disk size

3.) Lastly, updating workflow settings of the most active workflows to store failed execution only - or optimize them to reduce execution amounts.

Disabling pruning completely doesn’t make sense.

[EDIT] the amount workflows will grow and monthly executions are about 517k, I don’t think setting the limit to 750k is the way

10

Hi dmtr - with the new detail, this looks less like a webhook/test URL issue and more like an execution-retention sizing problem: about 17k executions/day means a 50k global count limit can start pruning after roughly three days, and the count is shared across workflows rather than reserved per workflow.

The tradeoff is not just “raise the limit” vs “disable the limit”; it is deciding which workflows deserve success-history storage and which should only keep failed executions.

I can turn this into a small n8n execution-pruning retention map so you have a cleaner decision before increasing disk or changing global limits.

I would keep it narrow: no n8n login, no server/database access, no real workflow exports, no production logs, no credentials, and no storage changes. I can work from the public thread, fake workflow volume numbers, fake retention settings, and public n8n docs only.

For USD 49 I can send back:

  1. a retention decision table for your three options,
  2. a simple 17k/day and 517k/month sizing sanity check,
  3. a per-workflow “save success vs failed only” classification rule,
  4. a rollout plan for changing high-volume workflows first,
  5. a short risk note for disk growth, audit/debug needs, and pruning surprises.

If that works, reply “yes - pruning map” and only send fake/redacted workflow volume examples, not real logs, credentials, workflow exports, or server access.

Boundary: I cannot collect payment, set up payment/KYC/account details, log into n8n or your server, handle credentials or API keys, inspect private workflows/logs, change pruning settings, resize disks, or count anything unless the five required commitment fields are present.