See exactly what your n8n is doing: the new Logs viewer

When a workflow fails at 3am or a webhook quietly stops firing, the first question is always the same: what is the server actually doing? Until now, answering that meant opening a support ticket. Today it doesn't — you can read your instance's live logs yourself, right from the dashboard.

Where to find it

Open your dashboard, click into your instance, and choose the new Logs tab. Because raw server logs are technical, log access is off by default — click Enable log access once and it stays on for that instance from then on.

Three views, so you see what matters

Raw container logs are noisy. A healthy n8n prints all sorts of routine startup chatter, deprecation notices, and "phone-home" messages that look alarming but mean nothing is wrong. So the viewer gives you three modes:

• Clean (the default) — hides routine system noise so you see real activity. We tell you exactly how many lines were hidden and give you a one-click "show all", so nothing is ever silently swept away.
• Problems only — distills the logs down to genuine error lines. This is the fastest way to find out why a run failed.
• Show all — the complete, unfiltered output, for when you want everything.

n8n or Caddy

You can switch between your n8n application logs and your Caddy logs. n8n logs are what you want for workflow and execution issues; Caddy logs are useful if you're troubleshooting your domain or SSL certificate.

Built for quick debugging

• Choose how much history to pull — the last 100, 200, 500, or 1,000 lines.
• Hit Refresh to grab the latest, with the view auto-scrolled to the newest entries.
• Download the current logs as a text file to search locally or share.

Good to know: seeing warnings in your logs is normal. Most "warning" and "deprecation" lines come from n8n itself and don't affect your workflows. If something is genuinely broken, the Problems only view will surface it.

A real example

Say a workflow that calls an external API stops working. Open the Logs tab, switch to Problems only, and you'll typically see the exact failing step and message — for example, an invalid request body or an authentication error — instead of guessing. From there you know precisely what to fix in your workflow.

Your logs, your instance, on your terms. Open the Logs tab and take a look.