n8n İzleme Mimarisi ve Hermes Pivotu
Bu yazı, 28 Nisan 2026 tarihli bir Claude Code oturumunun çıktısı: n8n MCP üzerinden yapılan hata taraması, bulunan sorunların root cause analizi, retest sonuçları, yeni günlük izleme routine’i ve Hermes projesindeki mimari pivot kararı.
Arka plan
Vault’a n8n MCP connector’ı entegre eden güncellemenin ardından “akışlarımı yönetebiliyor musun?” sorusuyla pratik bir test başlattım. Test sırasında gerçek üretim hataları tespit edildi, mimari kararlar alındı ve ileriye dönük bir izleme mekanizması kuruldu.
n8n MCP ile Keşfedilen Yapı
MCP üzerinden bağlanıldığında ortaya çıkan tablo:
- 1 personal project: Ege Bostancı
- 4 aktif workflow:
| Workflow | Tetikleyici |
|---|---|
| Dev.to n8n Tag Fetcher | Webhook |
| Global Error Handler | Error Trigger → HTML mail → Postgres mark_failed |
| Günlük Digest Mail v2 | Günlük 10:00 schedule + Hermes webhook |
| Kur Alarm + Günlük Finansal Özet | Her 4 saatte schedule + Hermes webhook |
Her workflow’da errorWorkflow bağlantısı, Idempotency Gate, Finalizer ve Postgres ledger mevcut. Yani Hermes self-healing paketi (24 Nisan’da kurulmuştu) tam ve devrede.
Hata Taraması — Son 7 Gün Gmail ”🚨 n8n Failed”
Gmail’de ”🚨 n8n Failed” konulu mailler tarandı.
Gerçek hatalar
| Tarih | Workflow | Node | Hata | Tekrar |
|---|---|---|---|---|
| 24 Nis ~16:00 | Günlük Digest Mail v2 | Idempotency Gate | Module 'pg' is disallowed | 4 retry |
| 27 Nis 08:00-08:51 | Kur Alarm | Gemini Yorum | Gemini rate limit (too many requests) | 3 fail |
Gerçek hata olmayan
- 24 Nis 10:55 — TEST — Error Handler Verify: test maili, üretim hatası değil.
Root Cause ve Uygulanan Fix’ler
pg modülü sandbox kısıtlaması
Neden: n8n, Code node içinde require('pg') çağrısına varsayılan olarak izin vermiyor — sandbox güvenlik kısıtlaması.
Fix: Coolify üzerinden n8n container’ına NODE_FUNCTION_ALLOW_EXTERNAL=pg environment variable eklendi. Değişiklik tüm workflow’ları kapsıyor.
Onay: 28 Nisan tarihli manuel retest’te iki workflow başarıyla tamamlandı.
Gemini rate limit
Neden: Bir saat içinde 3 çağrı limit’e çarptı. Büyük olasılıkla alert-branch ile morning-branch eş zamanlı tetiklendi ya da retry açıktı.
Durum: Düzeltme sonrası retest temiz geçti. Hata tekrarlarsa Gemini quota planı ve retry stratejisi incelenecek.
Manuel Retest Sonuçları
Production modunda her iki workflow da execute_workflow ile paralel çalıştırıldı:
- Günlük Digest Mail v2 ✅ success
- Kur Alarm + Günlük Finansal Özet ✅ success
Ana Karar — Hermes’ten B Planına Pivot
Hermes neydi?
WSL üzerinde çalışan bir Python AI agent: PC açıkken aktif, n8n webhook’larını tetikler, Postgres ledger’a yazar. Event-driven, gerçek zamanlı tepki verebilir bir mimari olarak tasarlanmıştı.
Pivot sebebi
Model tarafında bir sorun (provider rate / cost / quality — kesin sebep henüz netleşmedi). Hermes’in Python middleware katmanı sürdürülemez hale geldi.
Yeni plan — B Planı
Claude Code + scheduled remote agents: Anthropic cloud’unda cron tetikli remote agent’lar, n8n MCP ve Gmail MCP üzerinden iş yapar. Hermes’in WSL’deki Python sürecine gerek kalmaz.
Hermes’ten geriye kalanlar (korunacak)
Hermes pivot olsa da aşağıdaki bileşenler bağımsız değer taşıdığı için yerinde kalıyor:
| Bileşen | Neden kalsın |
|---|---|
| Idempotency Gate + Finalizer | Workflow retry/dedup için geçerli, Hermes’e bağımlı değil |
processed_requests Postgres ledger | Audit trail, bağımsız çalışıyor |
| Global Error Handler e-mail alerting | Tamamen bağımsız, dokunmaya gerek yok |
HERMES_CALLBACK_URL env var | Boşsa Finalizer zaten skip ediyor — kod değişmesin |
Değerlendirilen ama seçilmeyen alternatifler
- n8n native Langchain Agent nodu: Orchestration n8n içinde kalır ama agent capability sınırlı.
- n8n + direct LLM HTTP çağrıları (Hermes Python middleware’siz): Provider config her workflow başına tekrarlanır, ölçeklenmiyor.
B Planının sınırı
Event-driven değil, yalnızca cron tetikli. Anlık tepki gerekiyorsa hibrit çözüm gerekecek: n8n trigger → Claude Code webhook.
Kurulan Günlük İzleme Routine’i
| Parametre | Değer |
|---|---|
| Cron | 0 5 * * * UTC = 08:00 TR, her gün |
| Model | Claude Sonnet 4.6 |
| MCP connectors | n8n + Gmail |
Davranış (sırasıyla):
- Tüm workflow’ları tara —
active: falseolan var mı? - Gmail’de son 24 saatte ”🚨 n8n Failed” konulu mail var mı?
- Son 24 saatte
updatedAtdeğişmiş workflow’ları not et (informational) - Bir şey bulunursa Gmail’de tek draft oluştur; bulunmazsa sessiz geç
Kritik kısıt: Gmail MCP send tool’unu expose etmiyor, yalnızca create_draft. Bu nedenle raporlar inbox’a değil Drafts klasörüne düşer.
Hard kurallar: Auto-fix yok, workflow execute yok, workflow modify yok. Yalnızca tespit ve draft.
Drafts UX yetersiz gelirse plan: n8n’de bir “notification” workflow kurulur, agent oraya webhook atar — böylece mail gerçekten gönderilir.
Sonraki Adımlar
- 29 Nis 08:00 TR — Routine ilk gerçek run’ını yapar; Drafts klasöründe ne var bak
- ~12 Mayıs — 2 hafta sonra check-in: Drafts UX yetiyor mu, n8n notification workflow’una geçilmeli mi?
- Hermes pivot detayı — “Model sorunu” netleşince güncellenecek
- Gemini rate limit — Hata tekrarlarsa quota planı ve retry pattern review
İlgili yazılar
- Altyapı Çalışması — Tailscale VPN ve Quartz Geçişi — bu kararların alındığı altyapı
- VDS’ten Hetzner’e Göç — Coolify, Docker ve Çözülen Sorunlar — n8n’in çalıştığı VPS’in kurulum hikayesi