0 Production Executions Issue

Questions
1

I am running the latest Version of n8n (Gets automatically updated every day at 4 am, so I am sure its the latest stable build.) yet it shows 0 production executions lately. I have tested it and confirmed even though the executions themselves work in production, the statistics are completely broken. I avarage about 200k prod executions so something seems very wrong if the statistics show 0 but all executions still work.

Does anybody know what might be wrong?

n8n Debug Info:

core

  • n8nVersion: 2.17.7
  • platform: docker (self-hosted)
  • nodeJsVersion: 24.14.1
  • nodeEnv: production
  • database: postgres
  • executionMode: regular
  • concurrency: -1
  • license: enterprise (production)

storage

  • success: all
  • error: all
  • progress: false
  • manual: true
  • binaryMode: filesystem

pruning

  • enabled: true
  • maxAge: 1 hours
  • maxCount: 10000 executions

client

  • userAgent: mozilla/5.0 (windows nt 10.0; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/147.0.0.0 safari/537.36
  • isTouchDevice: false

security

  • secureCookie: false

Generated at: 2026-04-25T12:17:09.114Z

3

Hi @letsmanuel welcome

Your pruning config is extremely aggressive: maxAge = 1 hour with maxCount = 10,000. At ~200k executions per day, pruning is constantly deleting almost everything. The execution statistics/insights panel queries the executions table, so if rows are being wiped within an hour, the dashboard has very little to count.

Can you run a quick count directly against Postgres to see whatā€™s actually in the table?

SELECT status, COUNT(*) FROM execution_entity GROUP BY status;

That will tell us whether the data exists in the DB but the UI isnā€™t showing it (a bug) vs the data is genuinely being pruned before anything can display it (a config issue).

Since you auto-update daily, do you know roughly when this started? That would help pin it to a specific 2.17.x release.

If the DB query shows rows exist but the UI shows 0, thatā€™s a real bug worth filing on GitHub. If the DB is also near-empty, then your pruning window just needs to be wider.

Let me know :crossed_fingers:

4

Started about 3 days ago! (Could be a bit longer, but it was working 5 days ago!]

And about the pruning: I was always doing that without any problem, since it seems like the statistics are seperate from the actual table content. (Blatant guess based on what I observed over the last 3 months now.]

Also here is your output:
status | count
---------Ā±------
running | 2586
success | 4

If you wish, I can share the excact cleanup script that I am using, if that helps!

5

@letsmanuel that confirms itā€™s a bug, not a config issue. Your executions complete successfully but n8n isnā€™t flipping their status from running to success in the DB. Thatā€™s why stats show 0, and why you have 2,586 stuck executions (the docs say executions with running status are exempt from pruning, so they just accumulate).

Two things Iā€™d do:

File a GitHub issue with your debug info, the SQL output, and that it started 3-5 days ago after auto-update. The n8n version before and after the break would be extremely helpful if you have any logs or image pull history. This is a clear 2.17.x regression in how execution status is finalized.

Immediate cleanup for the stuck rows, yes please share your cleanup script. In the meantime, this should clear them:

UPDATE execution_entity SET status = ā€˜unknownā€™ WHERE status = ā€˜runningā€™ AND ā€œstartedAtā€ < NOW() - INTERVAL ā€˜2 hoursā€™;

(Using unknown rather than success since we donā€™t actually know if they all succeeded. Adjust the interval to whatever makes sense for your longest-running workflow.)

Also, consider pinning your docker image to the version that was working before as a temporary fix.

6 
pgq_check "DELETE execution_data" "DELETE FROM execution_data;"
pgq_check "DELETE execution_entity" "DELETE FROM execution_entity;"
pgq_soft "VACUUM FULL execution_data" "VACUUM FULL execution_data;"

if [ $? -ne 0 ]; then
  pgq_soft "VACUUM ANALYZE execution_data" "VACUUM ANALYZE execution_data;"
fi

pgq_soft "VACUUM FULL execution_entity" "VACUUM FULL execution_entity;"
if [ $? -ne 0 ]; then
  pgq_soft "VACUUM ANALYZE execution_entity" "VACUUM ANALYZE execution_entity;"
fi

pgq_soft "ANALYZE execution_data" "ANALYZE execution_data;"
pgq_soft "ANALYZE execution_entity" "ANALYZE execution_entity;"

Thanks for the reply. Above is the important part of the cleanup (Note: This does purge everything, but as stated worked previously) script. Before opening a bug report I thought iā€™d share it incase something is somehow suddenly wrong with it.

This script runs using a cronjob:
0 2 * * * cd /root/n8n_data && /bin/bash db_cleanup.sh >> /root/n8n_data/db_cleanup.log 2>&1

If nothing seems very wrong with the script however, I will open a bug report ofcourse!

7

I had the same issue after the recent update.

With pruning set to only 1 hour, the execution data gets deleted before the statistics can calculate and show the numbers. Thatā€™s why it displays 0 even though everything is actually running.

Try increasing the maxAge to at least 24 hours and see if the stats come back. That fixed it for me.

8

Iā€™ll try that! Thanks