n8n in Managed Services: Automating the Grind

Managed services runs on the same two-hour blocks every day: check the ticket queue, chase the device that dropped off, answer the "is the internet down?" email, look at the same eleven warnings that have been warning for a month. None of it is hard. All of it is time.

So the actual skill in this job isn't the fixing — it's deciding what not to do by hand. I've been using n8n for that decision for a while now, and this is the story of what it actually looks like inside a real L2 queue.

Why n8n

I could have written Python scripts cron-tabbed to the same server. I did, for years. The difference n8n makes is that it keeps the visible process — trigger, condition, action — in one place the whole team can read, instead of a folder of scripts that only one person fully understands.

More importantly, n8n talks to everything out of the box. The ticket API, the monitoring webhook, Teams, email, and any REST endpoint I throw at it — with retries, error handling and credential vaulting built in rather than re-built in every script.

The password rotation nobody wanted to do

Start small. The first workflow I shipped was a rotating shared password that policy said had to change every 90 days. Three devices, one API, one boring task that was exactly the sort of thing to silently not happen for six months.

The workflow is almost insultingly simple:

{
  "trigger": "cron: 0 2 1 */3 *",
  "steps": [
    { "action": "generate_password", "length": 24 },
    { "action": "update_device_secret", "target": "device-a" },
    { "action": "notify_channel", "channel": "ops" }
  ]
}

Generate, push, announce. Around it I wrapped an n8n Error Workflow — if any step fails, a second workflow fires and posts the failure with the traceback instead of silently swallowing it. A bot that quietly fails is worse than no bot, because now you also trust the thing you can't trust.

Disk-space triage you can actually ignore

Every monitoring platform generates the same kind of noise: 8TB volumes at 88% "critical," checked twice a day, nobody actioning it because it's twice a day and it's always at 88%.

Instead of ignoring the alert (a bad habit), I made the workflow action it. When the monitoring webhook fires, n8n checks the trend: is this volume growing at a rate that matters in the next 30 days? If yes, it opens a real ticket with the trend attached. If no, it closes the alert with a note: "Reviewed — 65 days until projected full, review again on ."

That one workflow removed a surprisingly large chunk of the daily queue, because the queue was mostly things that were being looked at but never decided. n8n makes the decision; people only see the exceptions.

The ticket digest nobody asked for

The most-used workflow isn't even the clever one. Every morning at 06:30 it pulls the open-ticket list from the ITSM API, groups by age and priority, dedupes the "is the internet down" repeats, and posts a one-screen summary to the ops channel.

// Code node — collapse 40 tickets into 1 digest
return [{
  json: {
    summary: events.map(e => ({
      id: e.ticket_id,
      age: e.age_days,
      priority: e.priority,
      label: e.title.slice(0, 120)
    })).sort((a, b) => b.age - a.age).slice(0, 25)
  }
}];

The side effect I didn't expect: people argue about the summary format in the morning stand-up. That's not a bug. Paraphrasing the queue every day made everyone aware of what a 90-day-old "open but stale" ticket actually looks like — and once you see five of them in one screen, closing them becomes a team decision, not a chore for whoever draws the short straw.

What I learned

1. Automate the boring decisions first, not the impressive ones. A password rotation protects nothing glamorous, but it's the workflow that outlived every flashier project.
2. Every workflow ships with an Error Workflow. If it can silently rot, it will. Fail loudly into a channel people actually read.
3. Idempotency is the co-pilot. The disk workflow re-runs on the same alert must not create five tickets. Check-then-create, or dedupe by a stable key, before you ever call the create endpoint.
4. The queue is mostly decisions, not work. Half the tickets in managed services are already-resolved situations waiting for someone brave enough to close them. Automating the decision is worth more than automating the action.
5. Lock down the credentials. n8n's built-in credential storage means tokens and passwords live in the vault, never in the workflow JSON. Exported workflows without secrets are also a great way to share one with a colleague.

The cost

• Money: $0. n8n runs self-hosted in Docker on the same box family I already run — though I keep it on a separate node from this site's own stack so the two don't fight over RAM.
• Maintenance: it's one more stack to keep updated. Worth it.
• Trust: the hardest line-item. It took a while before "the bot already handled it" was accepted as an answer in an incident call.

Automation in managed services isn't about replacing engineers. It's about making sure the engineers who stay are doing the work that needs judgment, and the machines handle the work that needs repetition. n8n just made that boundary visible — which was the first step to fixing it.

If you're in an L2 queue and your day still starts with manually typing the same four search terms into the ticket tool — that's your second-hour project. The first hour is telling n8n to do it for you.