Some n8n workflows have no execution history

أسئلة
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

تم تحديد المشكلة. المشكلة هي أن سير العمل لديه حوالي 17 ألف عملية تنفيذ يومياً. زيادة الحد الافتراضي من 10 آلاف و 7 أيام إلى 50 ألف و 30 يوماً لم يكن له تأثير كبير، لأنه بعد 3 أيام بدأ التنظيف بالفعل (حد 50 ألف). هذا تسبب في حذف عمليات التنفيذ ذات الحجم المنخفض والاحتفاظ بالعمليات عالية الحجم. يطبق حد 50 ألف على جميع سير العمل، وليس على كل منها على حدة.

الآن لدي 3 خيارات. أي واحد تنصح به؟

1.) تعيين حد التنفيذ إلى 250 ألف، والذي سيحتاج على الأرجح إلى حجم قرص أكبر للتخزين

2.) تعطيل حد الحجم والانتقال فقط إلى التنظيف القائم على الوقت (30 يوم). سيتطلب هذا أيضاً حجم قرص أكبر

3.) أخيراً، تحديث إعدادات سير العمل للسير الأكثر نشاطاً لتخزين عمليات التنفيذ الفاشلة فقط - أو تحسينها لتقليل كميات التنفيذ.

تعطيل التنظيف بشكل كامل لا معنى له.

[EDIT] عدد سير العمل سينمو وعمليات التنفيذ الشهرية حوالي 517 ألف، أنا لا أعتقد أن تعيين الحد إلى 750 ألف هو الطريقة الصحيحة

10

مرحبا dmtr - مع التفاصيل الجديدة، يبدو هذا أقل تعلقاً بمشكلة webhook/اختبار URL وأكثر تعلقاً بمشكلة حجم التنفيذ والاحتفاظ: حوالي 17k تنفيذ/يوم يعني أن حد العدد العام 50k يمكن أن يبدأ في الحذف بعد حوالي ثلاثة أيام، والعدد مشترك بين سير العمل بدلاً من أن يكون محجوزاً لكل سير عمل.

المقارنة ليست فقط “رفع الحد” مقابل “تعطيل الحد”؛ بل هي تحديد سير العمل الذي يستحق تخزين سجل النجاح وأيها يجب أن يحتفظ فقط بالتنفيذات الفاشلة.

يمكنني تحويل هذا إلى خريطة احتفاظ بحذف التنفيذ الصغيرة في n8n بحيث يكون لديك قرار أنظف قبل زيادة المساحة أو تغيير الحدود العامة.

سأبقيها ضيقة: بدون تسجيل دخول n8n، بدون وصول الخادم/قاعدة البيانات، بدون تصدير سير عمل حقيقي، بدون سجلات الإنتاج، بدون بيانات اعتماد، وبدون تغييرات التخزين. يمكنني العمل من المشروع العام، وأرقام حجم سير العمل المزيفة، وإعدادات الاحتفاظ المزيفة، ووثائق n8n العامة فقط.

مقابل 49 دولار يمكنني إرسال:

  1. جدول قرار الاحتفاظ لخياراتك الثلاثة،
  2. فحص صحة حجم بسيط لـ 17k/يوم و 517k/شهر،
  3. قاعدة تصنيف “حفظ النجاح مقابل الفشل فقط” لكل سير عمل،
  4. خطة طرح لتغيير سير العمل عالي الحجم أولاً،
  5. ملاحظة مخاطرة قصيرة لنمو القرص، احتياجات التدقيق/التصحيح، ومفاجآت الحذف.

إذا كان هذا مناسباً، ردّ بـ “نعم - خريطة الحذف” وأرسل فقط أمثلة حجم سير عمل مزيفة/معاد تحديدها، وليس سجلات حقيقية، أو بيانات اعتماد، أو تصدير سير عمل، أو وصول خادم.

الحد: لا يمكنني جمع الدفع، أو إعداد تفاصيل الدفع/KYC/الحساب، أو تسجيل الدخول إلى n8n أو الخادم الخاص بك، أو التعامل مع بيانات اعتماد أو مفاتيح API، أو فحص سير العمل/السجلات الخاصة، أو تغيير إعدادات الحذف، أو تغيير حجم الأقراص، أو عد أي شيء ما لم تكن حقول الالتزام الخمسة المطلوبة موجودة.