n8n VPS üzerinde neden çevrimdışı kalıyor?

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 farklı 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şlatılır. Ç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, 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 hatayı yaşadığınızı tespit edin. n8n, genellikle tek 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 kendi yöntemiyle bozulur ve tarayıcı bunların hepsini aynı mesajla bildirir.

Tanılama sırası

Bu komutları VPS (sanal özel sunucu) üzerinde çalıştırın ve kendi makinenizin döndürdüğü değerleri okuyun. Bu değerleri bir forum başlığındaki sayılarla kıyaslamayın. Burada önemli olan değerler, başkasının değil, sizin sunucunuzun durumunu tanımlar.

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ığı an ile kıyaslayın. Eğer container, hata 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 çıkış yaptığı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 yetersizliği bayrağı birlikte ne olduğunu açıklar; bunlardan sadece biri sizi yanıltabilir.

docker stats, anlık 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 gerçekleşirken 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 uzun ömürlü bir push bağlantısını açık tutar. Varsayılan olarak bu bağlantı, N8N_PUSH_BACKEND tarafından seçilen ve varsayılan değeri websocket olan bir WebSocket bağlantısıdır. 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 şey bozar ve her ikisi de n8n içinde değil, proxy katmanında gerçekleşir. Proxy, upstream tarafında HTTP/1.0 protokolünü kullanır veya upgrade başlıklarını kaldırır; bu durumda yükseltme işlemi gerçekleşmez ve düzenleyici sürekli olarak 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 algılayıp soketi kapatır. Her iki durumda da container sağlıklıdır. Görüntülenen uyarı, tarayıcının kanalı kaybettiğini 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 seçin 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 isteklerini iletmez. proxy_pass varsayılan olarak arka uçla HTTP/1.0 üzerinden haberleşir; Connection ve Upgrade ise nginx'in iletim sırasında kaldırdığı hop-by-hop başlıklardır. Her ikisini de tekrar eklemeniz gerekir. map bloğu server içine değil, http bağlamına yerleştirilmelidir. Aşağıdaki sunucu bloğunun geri kalanı size yabancı geliyorsa, nginx sunucu bloğunun satır satır açıklaması her yönergenin ne işe yaradığını anlatmaktadır.

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, insanları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 duran 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 artırmak, açık bıraktığınız bir sekmeye geri döndüğünüzde sizi karşılayan uyarı bandını düzeltir.

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ı tarafından dahil edilmeyen bir yapılandırma dosyası, doğru yapılan 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 değerini görmezden geldiği anlamına gelir. Bu değeri, container'ın ö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 etmekle birlikte başlangıçta bir uyarı mesajı yazdırır.

Traefik WebSocket bağlantılarını iletir ancak zaman aşımına uğratır

Traefik, herhangi bir ara katman (middleware) veya ek etiket olmadan bir WebSocket yükseltme isteğini iletir; bu nedenle bu uyarıyı gören bir Traefik kullanıcısı genellikle eksik bir başlıktan ziyade bir zaman aşımı sorunuyla karşılaşmaktadır. Ayarlar entryPoint üzerinde yapılandırı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 direktife ihtiyaç duymaz. Eğer proxy üzerinde hiçbir değişiklik yapamıyorsanız (çünkü yönetim başkasındadır), 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 bile çalışabilir; ancak agresif bir boşta kalma (idle) zaman aşımı yine de bağlantıyı kesebilir. Hangi proxy'nin seçileceği ayrı bir karardır ve Nginx, Caddy ve Traefik karşılaştırması her birinin operasyonel maliyetlerini detaylandırmaktadı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 hizalayın ve hemen öncesinde ne olduğuna bakın. Dört temel neden vakaların neredeyse tamamını açıklar: başlatmayı engelleyen bir yapılandırma hatası, n8n'in erişemediği bir veritabanı, çalışma sırasında meydana gelen bir çökme ve bellek yetersizliği nedeniyle sonlandırılma (OOM kill).

İzinler genellikle gözden kaçtığı için işe volume ile başlayın. 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ılamaz; bu nedenle süreç her seferinde başlatma sırasında ölür ve yeniden başlatma politikası 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ısında görülen 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 dosyaları kimin yazacağına nasıl karar verdiğini detaylandırır.

Çökme gibi görünen bellek yetersizliği 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 tarafından uygulanır: bu sınır aşıldığında süreç derhal sonlandırılır, herhangi bir veri yazma şansı kalmaz ve OOMKilled değeri true olarak okunur. V8 yığın (heap) sınırı ise Node.js içerisinde 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 çıkar; 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 ikisinden daha yüksekse, V8 çekirdeğin müdahale ettiği noktayı geçecek şekilde 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 başarısızlık durumuyla 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, veritabanı, proxy ve işletim sistemi için pay bırakarak seçin. 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.

Çalıştırma verisi altınızda büyüyen şeydir

Bir çalıştırma devam ederken her düğümün çıktısını tutar ve n8n bu veriyi depolar. Bunun iki sonucu vardır. Bir çalıştırmanın 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. Depolanan kopya ise bir şey onu silene kadar büyümeye devam eder.

Budama (pruning) ikinci sorunu çözer. Ağustos 2026 itibarıyla varsayılan ayarlar, budama etkin, EXECUTIONS_DATA_MAX_AGE 336 saat (14 gün) ve EXECUTIONS_DATA_PRUNE_MAX_COUNT 10000 olarak belirlenmiştir. Bunlar, SQLite çalıştıran ve her şeyin tek bir dosyada tutulduğu, düzenleyiciyi sunan sürecin aynı zamanda bu dosyayı okuyup yazmak zorunda olduğu 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. Başarısız çalıştırmaları hata ayıklama için tutar ve başarılı olanları atar. Buna bilinçli karar verin; çünkü hata vermeden 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 daha sonraki bir geçişte kaldırır; SQLite ise boşalan sayfaları işletim sistemine geri vermek 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, çalıştırma başına 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, ikili verileri çalışan yürütme sürecinin belleğinde tutan default değerini kullanır. 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 dosyayı getiren bir iş akışı, süreci normal JSON işlemlerinin asla yaklaşamayacağı bir sınırın ötesine itebilir; bu nedenle çökme, zamana bağlı 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ünün içinde bulunan ve dolayısıyla diğer her şeyle aynı birimde yer alan N8N_BINARY_DATA_STORAGE_PATH altına yazılır. Geçiş yapmadan önce birimde yeterli alan olduğundan emin olun. 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 alınmasına olanak tanır; ancak bu, kabul etmeyi seçtiğiniz bir bellek maliyetidir.

Sunucuyu paylaşan diğer tüm öğeler aynı RAM için rekabet eder. Eğer OOM (Out of Memory) kaynaklı durdurmalar bir veritabanı container'ı eklediğinizde başladıysa, veritabanını Docker içinde veya ana makinede çalıştırmak şu an yaptığınız ödünleşimin bir parçasıdır.

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 elle 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'ı da yeniden başlatır.

n8n, N8N_ENDPOINT_HEALTH ile adlandırılan ve varsayılan değeri healthz olan bir sağlık kontrolü uç noktası sunar. Yolun kendi örneğinizde 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 yanında bir yeniden başlatma politikasına veya harici bir izleyiciye ihtiyaç vardır. Gerçekten işlevsel bir sağlık kontrolü yazma ve yığın sistem yeniden başlatıldıktan sonra tekrar çalışacak şekilde yapılandırma konuları bu iki durumu da kapsamaktadır.

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

Bu durumda herhangi bir uyarı veya yeniden başlatma gerçekleşmez. Container çalışır durumdadır, düzenleyici arayüzü işlevseldir ancak beklediğiniz çalışma, yürütme listesinde görünmez. Bu sorunun temelinde genellikle dört neden yatar.

• İş akışı aktif değildir. Schedule Trigger yalnızca üretim yolunda çalışır; bu nedenle tuval üzerinde test etmek herhangi bir zamanlama oluşturmaz.
• Saat dilimi size uygun değildir. GENERIC_TIMEZONE varsayılan olarak America/New_York değerini kullanır; bu yüzden GENERIC_TIMEZONE ve TZ değerlerini kendi bölgenize göre ayarlayana kadar 09:00 için kurulan bir zamanlama, o saat dilimindeki 09:00'da tetiklenir.
• Kesinti süresi sonradan telafi edilmez. Tetikleyiciler n8n başladığında kaydedilir; bu nedenle container yeniden başlatılırken zamanı gelen bir görev, gecikmeli olarak çalıştırılmaz. Bir sonraki çalışma, başlatma işleminden sonraki ilk planlanan zamandır.
• İş akışı sizin yerinize devre dışı bırakılmıştır. N8N_WORKFLOW_AUTODEACTIVATION_ENABLED varsayılan olarak kapalıdır; bu özellik açıkken sürekli hata veren bir iş akışı yayından kaldırılır ve sonuçta hiç kimsenin aktif etmediği bir iş akışıyla aynı görünümü alır.

Yürütme listesini açın ve ilgili iş akışına göre filtreleyin. Başarısız bir kayıt varsa sorun iş akışındadır. Eğer aynı sunucuda barındırdığınız başka bir servise karşı 429 hatası alıyorsanız, bu sınırlama n8n'den ziyade o servise aittir ve SearXNG 429 rehberi, kendi hız sınırlayıcınızı sunucu IP'nizi engelleyen motorlardan nasıl ayırt edeceğinizi gösterir. Hiç kayıt oluşmuyorsa sorun tetikleyicidedir ve yukarıdaki dört nedene bakılmalıdır.

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

1. Herhangi bir dosyayı düzenlemeden önce kendi container'ınız üzerinde STATUS, RestartCount ve OOMKilled değerlerini okuyun.
2. Container hiç kapanmadıysa, proxy yükseltme başlıklarını (upgrade headers) 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ında tutun ve ikili verileri filesystem formatına geçirin.
4. Hiçbir tetikleyici çalışmadıysa, iş akışının etkin olduğunu ve örnek zaman diliminin (instance timezone) size ait olduğunu doğrulayın.

Bunların çoğu, çalışan bir kurulumun üzerine bir kez yapılıp unutulan yapılandırmalardır. Kurulumu henüz tamamlıyorsanız, HTTPS ile Docker üzerinde n8n kurulum kılavuzu, bu ayarların ait olduğu temel yapıyı oluşturur.

FAQ

n8n editörü, container çalışır durumda olmasına rağmen neden "bağlantı koptu" uyarısı veriyor?

Editör, yürütme ilerlemesini aktarmak 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 (upgrade) işlemi tamamlanamaz; n8n sağlıklı çalışsa 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 ve boşta kalan sekmelerin kesilmemesi için varsayılan 60 saniyeden daha uzun bir proxy_read_timeout değerine ihtiyacınız vardır. Düzenlediğiniz dosyayı değil, çalışan yapılandırmayı sudo nginx -T ile kontrol edin.

Bir işlemin bellek yetersizliğinden (OOM) mi yoksa normal bir çökmeden mi kaynaklandığını nasıl anlarım?

docker inspect n8n | grep -iE 'OOMKilled|ExitCode|RestartCount' komutunu çalıştırın ve OOMKilled bayrağını inceleyin. Değerin True olması, çekirdeğin (kernel) süreci bellek sınırını aştığı için sonlandırdığı anlamına gelir; süreç yazma şansı bulamadığı için container günlüğünde yararlı bir bilgi yer almaz. Değerin False olması ve docker logs dosyasının sonunda bir yığın (heap) hatası ile stack trace bulunması, Node.js'in kendi V8 heap sınırına ulaşıp kapandığını gösterir. NODE_OPTIONS=--max-old-space-size değerini container sınırınızın altında bir seviyeye ayarlayın; böylece hata oluştuğunda geride iz bırakan ikinci senaryo gerçekleşecektir.

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 temizlenir. 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 dosya boyutu bir süre sabit kalır. EXECUTIONS_DATA_MAX_AGE ve EXECUTIONS_DATA_PRUNE_MAX_COUNT değerlerini sunucunuza uygun şekilde ayarlayın ve sonucu hemen değil, bir sonraki gün kontrol edin.

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

n8n, tetikleyicileri süreç başladığında kaydeder ve kapalı olduğu süre boyunca zamanı gelen işleri geriye dönük olarak ç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 zaman diliminde gerçekleşir. Kaçırılmaması gereken iş akışlarınız varsa, bunları bir webhook üzerinden dışarıdan 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ı?

Tek 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 kapandıktan sonra onu tekrar ayağa kaldıran 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. Özellikle sağlıksız durumlar için aksiyon almak istiyorsanız, durumu izleyen ve servisi yeniden başlatan Docker dışı bir gözlemciye (watcher) ihtiyacınız vardır.