n8n VPS uzerinde neden surekli cevrimdisi kaliyor?

n8n neden çevrimdışı kalıyor: dört hata, tek bir belirti

"n8n çevrimdışı kalıyor" ifadesi, her biri farklı bir çözüm gerektiren dört ayrı hatayı kapsayan tek bir cümledir. Düzenleyici, container normal şekilde çalışırken bağlantının koptuğuna dair bir uyarı gösterir. Container kendi kendine yeniden başlar. Çekirdek (kernel), çok fazla bellek kullandığı için Node.js sürecini sonlandırır. Veya süreçte hiçbir sorun yoktur ancak aktif bir iş akışı (workflow) hiçbir zaman tetiklenmez. Yanlış ayarı değiştirirseniz, aslında hiç sahip olmadığınız bir sorunla uğraşarak hafta sonunuzu harcarsınız.

Bu nedenle, herhangi bir yapılandırmaya dokunmadan önce hangi hatayla karşılaştığınızı tespit edin. n8n, genellikle bir Docker container içinde, TLS (taşıma katmanı güvenliği) sonlandırması yapan bir reverse proxy arkasında, tek bir Node.js süreci olarak çalışır. Bu katmanların her biri kendine has biçimde bozulur ve tarayıcı bunların hepsini aynı mesajla bildirir.

Bu sırayla teşhis edin

Bu komutları VPS (sanal özel sunucu) üzerinde çalıştırın ve kendi makinenizin döndürdüğü değerleri okuyun. Bunları bir forum başlığındaki sayılarla karşılaştırmayın. Burada önemli olan değerler, başkasının değil, sizin sisteminizi tanımlayan değerlerdir.

docker ps -a --filter name=n8n
docker logs --tail 200 --timestamps n8n
docker inspect n8n | grep -iE 'Status|Running|RestartCount|OOMKilled|ExitCode'
docker stats --no-stream

docker ps -a çıktısındaki STATUS sütunu, container'ın mevcut durumunda ne kadar süredir kaldığını belirtir. Bu süreyi, sorununuzun başladığı anla karşılaştırın. Eğer container, uyarı mesajı görünmeden çok daha önce ayağa kalkmışsa, n8n hiçbir zaman çevrimdışı olmamıştır. Bozulan şey, tarayıcınız ile arka uç arasındaki bağlantıdır; bu, bir sonraki bölümde ele alınan websocket yoludur.

RestartCount, Docker'ın bu container'ı kaç kez yeniden başlattığını gösterir. Sayıyı not edin, bir dakika bekleyin ve tekrar okuyun. Siz izlerken artan bir sayı, yeniden başlatma döngüsüne (restart loop) işaret eder; her yeniden başlatmadan hemen önceki günlük kayıtları, sorunun nedenini içerir.

OOMKilled, doğru veya yanlış (true/false) değerini alan bir bayraktır. True değeri, Linux çekirdeğinin, container'ın kendi sınırı veya makinenin toplam sınırı aşıldığı için süreci sonlandırdığı anlamına gelir. Bu tek alan, bellek kaynaklı sonlandırmayı diğer tüm çıkış türlerinden ayırır; bu yüzden tahminde bulunmadan önce bu alanı okumalısınız.

ExitCode, container'ın en son hangi kodla çıktığını gösterir. Her kodun ne anlama geldiğini ezberlemenize gerek yoktur. Kendi kodunuzu okuyun ve ardından aynı zaman damgasına sahip docker logs dosyasının sonunu inceleyin. Günlük kaydının sonu ve bellek dışı (out of memory) bayrağı birlikte ne olduğunu açıklar; tek başlarına yanıltıcı olabilirler.

docker stats, mevcut bellek kullanımını uygulanan sınırla birlikte gösterir. Bu komutu ikinci bir terminalde çalışır durumda bırakın, soruna yol açan iş akışını tetikleyin ve hata oluştuğu sırada sayının nasıl değiştiğini izleyin.

Bağlantı koptu uyarısı genellikle reverse proxy kaynaklıdır

n8n düzenleyicisi, yürütme ilerlemesini tuval üzerine aktarabilmek için arka uç ile açık tutulan uzun ömürlü bir bağlantı kullanır. Varsayılan olarak bu bağlantı, N8N_PUSH_BACKEND ile seçilen ve varsayılan değeri websocket olan bir WebSocket'tir. Bir WebSocket, Connection: Upgrade ve Upgrade: websocket başlıklarını taşıyan sıradan bir HTTP isteği olarak başlar. Sunucu 101 Switching Protocols yanıtını verir ve o andan itibaren her iki taraf da aynı TCP soketini çift yönlü olarak kullanır.

Bu durumu iki faktör bozar ve her ikisi de n8n içinde değil, proxy katmanında yer alır. Proxy, upstream tarafında HTTP/1.0 kullanıyor veya upgrade başlıklarını kaldırıyorsa, yükseltme işlemi gerçekleşmez ve düzenleyici sürekli yeniden bağlanmaya çalışır. Ya da yükseltme başarılı olur ancak proxy, WebSocket üzerinden bir süre veri akışı olmadığında bağlantıyı boşta bir bağlantı olarak görüp kapatır. Her iki durumda da container sağlıklıdır. Görüntülenen uyarı, tarayıcının kanalla olan bağlantısının koptuğunu size bildirmesidir.

Herhangi bir düzenleme yapmadan önce durumu tarayıcı üzerinden doğrulayın. Geliştirici araçlarını açın, Network sekmesine gidin, WS filtresini uygulayın ve düzenleyiciyi yeniden yükleyin. Push isteği 101 Switching Protocols adresine ulaşmalı ve açık kalmalıdır. Sıradan bir durum kodu döndüren veya birkaç saniyede bir yeniden beliren bir push isteği, sorunun proxy kaynaklı olduğunu gösterir.

Editör bağlantısını koruyan nginx ayarları

nginx, siz talep etmediğiniz sürece upgrade isteğini iletmez. proxy_pass varsayılan olarak arka uçla HTTP/1.0 üzerinden konuşur; Connection ve Upgrade ise nginx'in iletim sırasında kaldırdığı hop-by-hop başlıklarıdır. Her ikisini de geri eklemeniz gerekir. map bloğu server içine değil, http bağlamına yerleştirilmelidir.

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 443 ssl;
    http2 on;
    server_name n8n.example.com;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
        proxy_buffering off;
    }
}

proxy_read_timeout, kullanıcıların eklemeyi unuttuğu satırdır. Varsayılan değeri 60 saniyedir ve yükseltilmiş bir WebSocket bağlantısı için de geçerlidir; bu nedenle boşta kalan bir örnekte açık bırakılan editör sekmesi, son mesajdan yaklaşık bir dakika sonra bağlantısını kaybeder. Bu değeri yükseltmek, açık bıraktığınız bir sekmeye geri döndüğünüzde sizi karşılayan uyarı bandını çözer.

sudo nginx -t && sudo systemctl reload nginx
sudo nginx -T | grep -iE 'proxy_http_version|upgrade|proxy_read_timeout'

nginx -T, tek bir dosya yerine çalışan tüm yapılandırmayı yazdırır; böylece yaptığınız düzenlemenin gerçekten yüklendiğini kanıtlar. Hiçbir include satırının dahil etmediği bir dosyada kalan yapılandırma, doğru bir düzeltmenin hiçbir işe yaramıyor gibi görünmesinin nedenidir.

Ardından n8n'e bir proxy arkasında olduğunu bildirin, çünkü n8n URL'leri bu değerlere göre oluşturur.

environment:
  - N8N_HOST=n8n.example.com
  - N8N_PROTOCOL=https
  - N8N_PORT=5678
  - N8N_PROXY_HOPS=1
  - N8N_WEBHOOK_URL=https://n8n.example.com/

N8N_PROXY_HOPS varsayılan olarak 0 değerindedir; bu, n8n'in bağlanan adresi istemci adresi olarak kabul ettiği ve X-Forwarded-For başlığını görmezden geldiği anlamına gelir. Bu değeri, container önündeki proxy sayısına göre ayarlayın. Ağustos 2026 itibarıyla N8N_WEBHOOK_URL güncel isimdir; daha eski olan WEBHOOK_URL ise çalışmaya devam eder ancak başlatma sırasında bir kullanımdan kaldırma uyarısı verir.

Traefik WebSocket trafiğini yönlendiriyor ancak zaman aşımına uğratıyor

Traefik, herhangi bir ara yazılım (middleware) veya ek etiket olmaksızın WebSocket yükseltme (upgrade) isteğini iletir. Bu uyarıyı gören bir Traefik kullanıcısı, eksik bir başlıktan ziyade genellikle bir zaman aşımı sorunuyla karşılaşmaktadır. Ayarlar entryPoint üzerinden yapılır. Ağustos 2026 itibarıyla Traefik v3 sürümünde idleTimeout varsayılan olarak 180 saniye, readTimeout ise varsayılan olarak 60 saniye olarak ayarlanmıştır.

entryPoints:
  websecure:
    address: ":443"
    transport:
      respondingTimeouts:
        readTimeout: 0
        idleTimeout: 3600s

Caddy, yükseltme işlemini reverse_proxy içerisinde otomatik olarak yönetir ve bunun için herhangi bir yönerge gerektirmez. Proxy üzerinde değişiklik yapma yetkiniz yoksa, push kanalını N8N_PUSH_BACKEND=sse ile değiştirmeyi deneyin. SSE (server-sent events), açık tutulan normal bir HTTP yanıtı olduğu için yükseltme isteklerini reddeden bir proxy üzerinden çalışabilir; ancak agresif bir boşta kalma (idle) zaman aşımı ayarı bağlantıyı yine de kesebilir. Hangi proxy'nin kullanılacağı ayrı bir karar konusudur ve Nginx, Caddy ve Traefik karşılaştırması bölümü, her birinin operasyonel maliyetlerini açıklamaktadır.

Konteyner sürekli yeniden başlatıldığında

Eğer RestartCount artıyorsa, konteyner başarısız oluyor ve Docker onu tekrar ayağa kaldırmaya çalışıyordur. Günlük kayıtlarındaki zaman damgalarını yeniden başlatma anlarıyla eşleştirin ve hemen öncesinde ne olduğuna bakın. Dört temel neden çoğu durumu açıklar: başlatmayı engelleyen bir yapılandırma hatası, n8n'in erişemediği bir veritabanı, çalışma anında meydana gelen bir çökme ve bellek yetersizliği nedeniyle sonlandırılma (OOM kill).

İşe volume ile başlayın, çünkü izin sorunları genellikle sessizce gerçekleşir. Resmi imaj, yetkisiz node kullanıcısı olarak çalışır ve verilerini /home/node/.n8n dizininde tutar. root tarafından oluşturulan bir bind mount, bu kullanıcı tarafından yazılabilir değildir; bu nedenle süreç her seferinde başlatma aşamasında ölür ve yeniden başlatma politikası (restart policy) bu durumu bir döngü arkasına gizler.

docker compose config
docker run --rm -it --entrypoint sh docker.n8n.io/n8nio/n8n -c 'id'
docker exec n8n ls -ld /home/node/.n8n

Named volume kullanımı bu sorunu tamamen ortadan kaldırır, çünkü Docker bu alanı doğru sahiplik bilgileriyle oluşturur. Eğer bind mount kullanmanız gerekiyorsa, ilk komutun çıktı olarak verdiği sayısal kullanıcı kimliğini kullanarak ana makinedeki dizini chown ile güncelleyin. Ana makine ile konteyner arasındaki sahiplik eşlemesini bir kez anlamak faydalıdır; PUID ve PGID açıklayıcısı, bu imajların dosya yazma yetkisini kime vereceğine nasıl karar verdiğini detaylandırır.

Çökme gibi görünen bellek yetersizliği (OOM) sonlandırması

Bir n8n sürecinin üzerinde birbirinden bağımsız iki bellek sınırı bulunur ve bu sınırlar farklı şekillerde başarısız olur. Container kontrol grubu sınırı çekirdek (kernel) tarafından uygulanır: bu sınır aşıldığında süreç derhal sonlandırılır, herhangi bir kayıt yazma şansı kalmaz ve OOMKilled değeri true olarak okunur. V8 yığın (heap) sınırı ise Node.js içinde uygulanır: bu sınır aşıldığında Node bir yığın hatası fırlatır, yığın izini (stack trace) oluşturur ve kendiliğinden kapanır; bu durumda OOMKilled değeri false olarak okunur. Tarayıcı üzerinden bakıldığında bu iki durum aynı görünür. docker inspect üzerinden bakıldığında ise aralarında tek bir alan farkı vardır.

Node yığın sınırını, container sınırının altında belirleyin. Eğer yığın sınırı bu iki değerden yüksekse, V8 çekirdeğin müdahale ettiği noktayı geçene kadar bellek ayırmaya devam eder; bu nedenle çöp toplayıcı (garbage collector) kendi sınırına asla ulaşamaz ve her zaman okunabilir bir günlük kaydı bırakmayan daha sert bir hata ile karşılaşırsınız.

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    environment:
      - NODE_OPTIONS=--max-old-space-size=<MiB, below the container limit>
    deploy:
      resources:
        limits:
          memory: <your container limit>

Her iki değeri de VPS'nizin mevcut kaynaklarına göre seçin ve veritabanı, proxy ile işletim sistemi için pay bırakın. docker stats --no-stream, mevcut kullanımı uygulanan sınırın yanında yazdırır; böylece yazdığınız sınırın Docker tarafından uygulanan sınır olduğunu doğrulayabilirsiniz. Compose bellek sınırları nasıl uygulanır bölümü, birden fazla sınır ayarlandığında hangi anahtarın geçerli olduğu konusunu detaylandırır.

Yürütme verisi altınızda büyüyen bir yapıdır

Tek bir yürütme, çalışma devam ettiği sürece her düğümün çıktısını tutar ve n8n bu veriyi depolar. Bunun iki sonucu vardır. Bir yürütmenin tepe bellek kullanımı, içinden geçirdiğiniz en büyük veri yığını tarafından belirlenir; bu nedenle on bin satırı aynı anda işleyen bir iş akışı, aynı iş akışının iki yüz satırı bir kerede işlemesinden farklı bir programdır. Ayrıca depolanan kopya, bir şey onu silene kadar büyümeye devam eder.

Budama (pruning) ikinci sorunu çözer. Ağustos 2026 itibarıyla varsayılan ayarlar, budamanın etkin olması, EXECUTIONS_DATA_MAX_AGE değerinin 336 saat (14 gün) ve EXECUTIONS_DATA_PRUNE_MAX_COUNT değerinin 10000 olmasıdır. Bunlar, her şeyin tek bir dosyada tutulduğu ve editöre hizmet veren sürecin aynı zamanda bu dosyayı okuyup yazmak zorunda olduğu SQLite çalıştıran küçük bir VPS için cömert değerlerdir.

environment:
  - EXECUTIONS_DATA_PRUNE=true
  - EXECUTIONS_DATA_MAX_AGE=72
  - EXECUTIONS_DATA_PRUNE_MAX_COUNT=1000
  - EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
  - EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false

EXECUTIONS_DATA_SAVE_ON_SUCCESS=none agresif ayardır. Hata ayıklama için başarısız yürütmeleri tutar ve başarılı olanları atar. Buna bilinçli karar verin; çünkü bir hata oluşturmadan yanlış çıktı üreten bir iş akışı, incelemeniz için geriye hiçbir şey bırakmaz. Budama işlemi ayrıca satırları önce silinmiş olarak işaretler ve sonraki bir geçişte kaldırır; SQLite ise boşalan sayfaları işletim sistemine iade etmek yerine yeniden kullanır, bu nedenle ayarı değiştirdiğiniz anda diskteki dosya boyutu küçülmez.

Depolanan toplam veriyi değil de tepe kullanımını azaltmak için, her yürütmede daha az veri taşıyın. Büyük işleri, ana iş akışına küçük sonuçlar döndüren alt iş akışlarına bölün, Loop Over Items düğümü ile gruplandırın ve veri setlerinin tamamını Code düğümünün dışında tutun.

İkili dosyalar bellek üzerinden taşınmamalıdır

N8N_DEFAULT_BINARY_DATA_MODE varsayılan olarak default değerini kullanır; bu da ikili verileri çalışan sürecin belleğinde tutar. Bir düğümün indirdiği her dosya ve bir sonraki düğüme aktarılan her kopya, çalışma süreci bitene kadar bellekte kalır. Birkaç büyük ek dosya alan bir iş akışı, süreci normal JSON işlemlerinin asla yaklaşamayacağı bir sınırın ötesine itebilir; bu nedenle çökme zamanlamaya değil, belirli bir iş akışına bağlı olarak gerçekleşir.

environment:
  - N8N_DEFAULT_BINARY_DATA_MODE=filesystem

filesystem ile ikili veriler, varsayılan olarak n8n kullanıcı klasörü içinde yer alan N8N_BINARY_DATA_STORAGE_PATH dizinine yazılır ve dolayısıyla diğer her şeyle aynı birim (volume) üzerinde konumlanır. Geçiş yapmadan önce birimin yeterli alana sahip olduğunu kontrol edin. N8N_PAYLOAD_SIZE_MAX, MiB (mebibyte) cinsinden en büyük gelen webhook yükünü belirler ve varsayılan değeri 16'dır. Bu değeri artırmak daha büyük isteklerin kabul edilmesini sağlar; ancak bu, kabul etmeyi seçtiğiniz bir bellek maliyetidir.

Sunucuyu paylaşan diğer tüm süreçler aynı RAM için rekabet eder. Eğer OOM (Out of Memory) kaynaklı sonlandırmalar bir veritabanı container'ı eklediğinizde başladıysa, veritabanını Docker içinde veya ana makinede çalıştırmak şu an yaptığınız tercihin bir sonucudur.

Yeniden başlatma politikası ve sistem yeniden başlatıldıktan sonra geri dönme

Yeniden başlatma politikası olmayan bir container, kapandıktan sonra veya ana makine yeniden başlatıldığında kapalı kalır. restart: unless-stopped, her iki durumda da container'ı geri getirir ancak manuel olarak durdurduğunuz bir container'a müdahale etmez. restart: always ise Docker bir sonraki sefer başladığında, kasıtlı olarak durdurduğunuz bir container'ı dahi yeniden başlatır.

n8n, healthz varsayılan değerine sahip N8N_ENDPOINT_HEALTH adında bir sağlık kontrolü uç noktası sunar. Yolun kendi kurulumunuzda doğru olduğundan emin olmak için önce ana makine üzerinden kontrol edin.

curl -fsS http://127.0.0.1:5678/healthz
docker exec n8n which wget curl
sudo systemctl is-enabled docker

Bir sağlık kontrolü tek başına hiçbir şeyi yeniden başlatmaz. Compose, container'ı sağlıksız olarak işaretler ve orada durur; bu nedenle sağlık kontrolünün bir etkisi olması için bir yeniden başlatma politikasına veya yanında harici bir izleyiciye ihtiyacı vardır. Gerçekten işlevsel bir sağlık kontrolü yazma ve stack'i yeniden başlatma sonrasında tekrar ayağa kaldırma konuları bu iki durumu da kapsamaktadır.

n8n çalışırken tetiklenmeyen iş akışları

Bu durumda herhangi bir uyarı mesajı oluşmaz ve yeniden başlatma gerçekleşmez. Container çalışır durumdadır, düzenleyici arayüzü yanıt verir ancak beklenen çalışma, yürütme listesinde görünmez. Sorunun temelinde genellikle dört neden yatar.

• İş akışı aktif değildir. Schedule Trigger yalnızca üretim yolunda çalışır; bu nedenle tuval üzerinde test edildiğinde herhangi bir zamanlama tetiklenmez.
• Zaman dilimi size uygun değildir. GENERIC_TIMEZONE varsayılan olarak America/New_York değerini kullanır. Bu nedenle, GENERIC_TIMEZONE ve TZ değişkenlerini kendi yerel ayarlarınıza göre yapılandırmadığınız sürece, 09:00 için kurulan bir zamanlama o bölgenin saatine göre tetiklenir.
• Kesinti sonrası telafi çalışması yapılmaz. Tetikleyiciler n8n başladığında kaydedilir. Bu nedenle, container yeniden başlatılırken zamanı gelen bir iş akışı, sistem açıldıktan sonra geriye dönük olarak çalıştırılmaz. Bir sonraki çalışma, sistem açılışından sonraki ilk planlanan zamandır.
• İş akışı sizin bilginiz dışında devre dışı bırakılmıştır. N8N_WORKFLOW_AUTODEACTIVATION_ENABLED varsayılan olarak kapalıdır. Bu özellik açık olduğunda, sürekli hata veren bir iş akışı yayından kaldırılır ve sonuçta iş akışı, hiç kimse tarafından aktif edilmemiş gibi görünür.

Yürütme listesini açın ve ilgili iş akışına göre filtreleme yapın. Başarısız olan bir kayıt varsa sorun iş akışındadır. Hiç kayıt yoksa sorun tetikleyicidedir ve yukarıda belirtilen dört neden incelenmelidir.

İlk olarak nelerin değiştirilmesi gerektiği

1. Herhangi bir dosyayı düzenlemeden önce kendi container'ınız üzerinde STATUS, RestartCount ve OOMKilled belgelerini okuyun.
2. Container hiç kapanmadıysa, proxy yükseltme (upgrade) başlıklarını ve boşta kalma zaman aşımını (idle timeout) düzeltin.
3. OOMKilled değeri true ise, bilinçli olarak seçtiğiniz bir container sınırı belirleyin, Node yığın (heap) üst sınırını bunun altına çekin ve ikili verileri filesystem moduna geçirin.
4. Hiçbir tetikleyici çalışmadıysa, iş akışının aktif olduğunu ve örnek zaman diliminin (timezone) size uygun olduğunu kontrol edin.

Bunların çoğu, çalışan bir kurulumun üzerine bir kez yapılandırıp unutacağınız ayarlardır. Eğer kurulumu hala oluşturuyorsanız, HTTPS ile Docker üzerinde n8n kurulumu kılavuzu, bu ayarların ait olduğu temel yapıdır.

FAQ

n8n düzenleyicisi, container çalışır durumdayken neden bağlantı koptu uyarısı veriyor?

Düzenleyici, yürütme ilerlemesini akıtmak için açık bir WebSocket bağlantısı tutar. Reverse proxy'niz Connection: Upgrade ve Upgrade: websocket başlıklarını iletmiyorsa veya upstream tarafında HTTP/1.1 kullanmıyorsa, yükseltme işlemi tamamlanamaz ve n8n sağlıklı kalsa bile tarayıcı sürekli yeniden bağlanmaya çalışır. Nginx tarafında proxy_http_version 1.1 yönergesine ek olarak her iki proxy_set_header satırına da ihtiyacınız vardır; ayrıca boşta kalan sekmelerin kesilmemesi için proxy_read_timeout değerini varsayılan 60 saniyeden daha uzun bir süreye ayarlamalısınız. Düzenlediğiniz dosyayı değil, sudo nginx -T komutu ile çalışan yapılandırmayı kontrol edin.

Bir "out of memory" (bellek yetersizliği) hatasını normal bir çökmeden nasıl ayırt ederim?

docker inspect n8n | grep -iE 'OOMKilled|ExitCode|RestartCount' komutunu çalıştırın ve OOMKilled bayrağını inceleyin. "True" değeri, çekirdeğin (kernel) bellek sınırını aştığı için süreci sonlandırdığını gösterir; bu durumda süreç yazma fırsatı bulamadığı için container günlüğünde yararlı bir bilgi yer almaz. "False" değeri ile birlikte docker logs dosyasının sonunda bir yığın (heap) hatası ve iz dökümü (stack trace) varsa, Node.js kendi V8 yığın sınırına ulaşmış ve kendiliğinden çıkış yapmıştır. NODE_OPTIONS=--max-old-space-size değerini container sınırınızın altında bir seviyeye ayarlayın; böylece kanıt bırakan ikinci türdeki hatayı alırsınız.

Yürütme verilerini temizlemek disk alanını hemen boşaltır mı?

Hayır. EXECUTIONS_DATA_PRUNE eski yürütmeleri silinmek üzere işaretler ve bunlar EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL ile belirlenen zamanlamaya göre daha sonraki bir aşamada kaldırılır. SQLite kullanıldığında, dosya boşalan sayfaları dosya sistemine geri vermek yerine yeniden kullanır; bu nedenle satırlar silindikten sonra bile disk üzerindeki boyut bir süre sabit kalır. EXECUTIONS_DATA_MAX_AGE ve EXECUTIONS_DATA_PRUNE_MAX_COUNT değerlerini sunucunuza uygun şekilde ayarlayın ve hemen değil, bir sonraki gün tekrar kontrol edin.

Zamanlanmış iş akışım n8n yeniden başlatılırken neden çalışmadı?

n8n, tetikleyicileri süreç başladığında kaydeder ve kapalı olduğu sırada zamanı gelen zamanlamaları tekrar çalıştırmaz. Bu nedenle bir yeniden başlatma döngüsü, kaçırılan işlerin toplu olarak çalıştırılması yerine sessizliğe neden olur; bir sonraki yürütme, başlatma sonrasındaki ilk zamanlama anında gerçekleşir. Kaçırılmaması gereken iş akışlarınız varsa, bunları bir webhook üzerinden dış bir çağrıcı ile tetikleyin; böylece yeniden deneme mantığı n8n dışında kalmış olur.

Bir sağlık kontrolü (healthcheck), n8n yanıt vermeyi bıraktığında onu yeniden başlatır mı?

Kendi başına hayır. Bir Compose sağlık kontrolü, container'ı yalnızca sağlıklı veya sağlıksız olarak işaretler. Yeniden başlatma işlemi, yeniden başlatma politikasının görevidir; bu nedenle restart: unless-stopped, container çıkış yaptıktan sonra onu geri getiren ayardır ve Docker servisi etkin olduğu sürece sunucu yeniden başlatıldığında da çalışmasını sağlar. Bunu sudo systemctl is-enabled docker ile doğrulayın. Sağlıksız durumlar için özel bir işlem yapmak istiyorsanız, durumu okuyan ve servisi yeniden başlatan, Docker dışında çalışan bir izleyiciye ihtiyacınız vardır.