When a company grows and its systems become a constellation of microservices, integrations, webhooks, and notification channels, the old "everything in Slack" strategy collapses. Too many notifications become noise, too few become a missed incident, and when something fails along the way no one knows if it was the network, the schema, authentication, or a rule error. It was to solve this problem in our own operation that we built a self-healing DevOps Central Hub on n8n, with schema validation, an auto-recovery engine, and intelligent routing to multiple channels.
This post documents the architecture, the decisions, and the lessons that made this hub the heart of our DevOps operation in 2026, and why we recommend this pattern for companies that want to operate with quality without increasing headcount linearly.
The original problem
We had the typical story of an engineering company: GitHub, Slack, WhatsApp, Discord, logs, dashboards, email. Each system shouting in its own tone. Four problems piled up. 1. Inconsistent notifications: the same event appeared in three channels in a different format, or did not appear at all. 2. Silent failures: a webhook that went down triggered nothing, and we found out from the client. 3. Unstable schema: GitHub changed the payload, the integration broke, and the error died in some log no one looked at. 4. No auditing: hard to reconstruct what happened during an incident.
Solving this with code distributed across several services was expensive and fragile. We chose to build a central event hub on n8n, with explicit layers, rigorous validation, and the ability to recover from failures without human intervention.
The 4 main sections of the hub
The architecture is divided into four blocks that work together like a conveyor belt.
1. Event ingestion. It receives signals from three sources: Schedule (internal cron, periodic jobs), HTTP Webhook (any external system), and GitHub Events (pull requests, issues, workflow runs). All of them pass through a Merge Triggers node that normalizes the format and injects metadata (source, type, timestamp, correlation_id) before proceeding.
2. SDD - Schema Validation. Every message is validated against a declared schema (versioned JSON Schema). Valid events proceed to the router; invalid events go to a Validation Error Log node and trigger an alert to the platform team. This is Spec-Driven Development applied to operations: the contract is explicit, failures are detected early, and the integration does not die in silence when a provider changes its payload.
3. Self-Healing Engine. The engine that sets this hub apart from a common conveyor belt. It has three capabilities: retry with exponential backoff on transient failures (network, rate limit, timeout); automatic re-execution of idempotent steps after a circuit breaker; fallback routing that chooses an alternative channel when the primary one goes down (e.g. Slack down, Discord; WhatsApp down, email). All of this is instrumented with metrics so the team can see, on a dashboard, when the system healed itself.
4. Output channel. Routing by priority and event type to the right channels: Slack for continuous operational traffic, WhatsApp/Signal for critical alerts outside business hours, Discord for the internal technical channel, an audit logger for immutable storage, a dashboard update for a real-time view.
The flow in practice
An event comes in through the webhook. Webhook Entry receives it, records the receipt, assigns a correlation_id. Merge Triggers normalizes the format together with schedule and GitHub events. SDD Validator runs the corresponding schema. If it passes, it goes to Standard Processor or Critical Processor depending on classification. Priority Sorter sets the urgency. Message Formatter assembles the final content per channel (template and tone vary: Slack allows rich blocks; WhatsApp is short text). Channel Router decides the destination. Self-Heal Decision kicks in if any channel fails, redirecting to a fallback. Each output (Slack Send, WhatsApp Send, Discord Send, Audit Logger) records a confirmation or error back to the observability loop.
Why n8n and not pure code
Five reasons weighed in. 1. Visibility: anyone on the team can look at the diagram and understand the flow. In pure code, it takes hours. 2. Fast iteration: adjusting a routing rule or a message template is dragging a node, not a deploy. 3. Execution history: each execution is recorded with the payload at each node, making debugging and auditing easier. 4. Node ecosystem: ready-made integrations for Slack, GitHub, Discord, WhatsApp (via API), Telegram, email, Notion, Postgres. 5. Self-hosted: it runs on our infrastructure, with no per-execution cost and no sensitive data leaving.
Real trade-offs: very complex logic in a Code node becomes hard to test. For those cases, we export it to a microservice called via HTTP. The hub handles orchestration and contracts; domain logic stays in services versioned in Git.
Auditing and compliance
Every event is recorded in append-only storage (BigQuery + cold bucket) with the original and normalized payload, the decisions made, and the result on each channel. This solves three problems: (1) reconstructing an incident; (2) proving SLA (when we notified, through which channel, with what latency); (3) compliance, for demands that require traceability.
Self-healing in practice: what heals itself
Five typical scenarios. Slack rate limit: retry with backoff until the window opens. Unstable GitHub webhook: retry pulling the status via API, without losing the event. WhatsApp channel down: automatic fallback to Discord + email, with a note "primary channel unavailable". GitHub schema changed: the schema validator detects it, alerts the platform, marks the event as "quarantined" for review without blocking the others. Stuck schedule job: a detector identifies the missing expected execution and fires a second trigger.
Metrics and observability of the hub
We track seven metrics on a dashboard. Events processed per minute. End-to-end p50/p95/p99 latency. Validation OK rate vs schema error. Self-heal triggering by type. Definitive failure by channel. SLA by event class. Execution cost (n8n compute and external calls).
What changed in our day-to-day
Three immediate effects. (1) The average incident detection time dropped drastically; before, someone had to cross-reference logs. (2) Duplicate and noisy notifications disappeared; each event has the right destination, and the right tone. (3) Schema changes became a non-event; when GitHub touches a payload, the hub warns, isolates, and we move on. The cost of maintaining integrations dropped because the hard work was done once in the skeleton, instead of scattered across services.
Who can use this architecture
Companies with at least three active integrations, a small technical team, and a need for predictable operations. It is the sweet spot: enough complexity to justify the hub, enough lightness to get it off the ground in weeks. For smaller teams, Slack + a few webhooks is already enough. For very large teams, a dedicated event platform (Kafka, EventBridge) with the hub as an orchestration layer is worthwhile.
The next step: AI inside the hub
We are integrating AI agents at specific points of the hub. Automatic issue triage (classification, priority, owner suggestion). A daily executive summary for leadership. Pattern detection in recurring incidents. Each use enters the hub with schema validation and self-heal, without becoming a black box. The architecture was designed with this next chapter in mind: AI-augmented operations, with governance and observability from the first byte.