Hello guys
I’m scaling a multi-tenant n8n platform and starting to realize that basic logs are no longer enough.
Load Balancer
↓
Multiple n8n Workers
↓
PostgreSQL + Redis + External APIs
As the number of tenants and workflows grows, I’m finding it difficult to answer questions like:
• Which tenant is generating the most load?
• Why did a specific workflow fail?
• Where are the bottlenecks in the system?
• Which external APIs are causing latency?
• How do I detect problems before customers notice?
I’m considering adding:
• Centralized logging
• Metrics collection
• Distributed tracing
• Per-tenant dashboards
• Alerting and anomaly detection
tenant_id
workflow_id
execution_time
error_rate
queue_depth
API_latency
Describe the problem/error/question
What observability stack are you using?Which metrics have been the most valuable?
What is the error message (if any)?
Please share your workflow
(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)
Hello @Selena_Gloria Once you start scaling to more tenants and workflows, it becomes much harder to understand what’s happening by looking at logs alone.
A common production setup includes:
Centralized logs
Metrics collection
Alerts
Tracing (when needed)
The metrics I find most useful are:
•tenant_id
•workflow_id
•Execution time
•Error rate
•Queue depth
•External API response time
Tagging logs and metrics with tenant_id makes it much easier to troubleshoot issues for a specific customer without affecting everyone else.
I’d also recommend setting up alerts for things like high error rates, growing queue backlogs, worker failures, slow APIs, and unexpected traffic spikes. That way, you can catch problems before users start reporting them.
One mistake to avoid is relying only on application logs or only monitoring your infrastructure. Having visibility into both your infrastructure and your workflows gives you a much better understanding of what’s happening.
Overall, a combination of centralized logging, metrics, dashboards, and alerts makes it much easier to keep the platform healthy as it grows.
I’d add one metric that is not really infra: a per-run action receipt.
Tenant, workflow, error rate, and latency tell you where the pain is. The receipt tells the customer what happened: expected run, credential/account used, records touched, external API called, final object/message id, and paused or retry state.