Most n8n tutorials stop at "connect node A to node B." The interesting part starts after that: what the workflow does when the API is down, where the secrets live, and how you remember what you built six months later.
The six templates in our workflow library are the ones we actually reach for. Every one is a plain .json file you can drop into n8n with Import from File, none contain credentials, and each carries a sticky note on the canvas explaining what to change. This post walks through what they do and the handful of patterns that show up across all of them.
The six templates
URL Healthcheck Alerter — A cron trigger every five minutes, a hardcoded list of URLs, a splitOut node to fan them into one item per URL, an HTTP probe, and an alert when the status code is 400 or above. It is the smallest useful monitor you can run, and it is a good first import because it exercises the fan-out pattern.
Local LLM RSS Digest — Fetches a feed at 07:00, builds a prompt from the raw XML, posts it to an OpenAI-compatible endpoint at http://host.docker.internal:8080/v1/chat/completions, and pulls the summary out of choices[0].message.content. Point it at Lemonade, vLLM, or an Ollama proxy; the shape of the request is the same. The delivery step is deliberately left unwired so you can pick email, Discord, or n8n chat.
Webhook → Discord — Four nodes. Accept a POST, normalize whatever shape arrived into a single content string, forward it to a Discord webhook. Swap the JSON body and it posts to Slack or Mattermost instead.
GitHub Release Watcher — Polls a repo's releases/latest every six hours and notifies only when the tag changes. The deduplication is the interesting part, covered below.
Manual Prompt → Lemonade — A manual trigger, a prompt, one HTTP call. This exists to answer "is my local model actually reachable from inside the n8n container?" before you debug a five-node workflow that was never going to work.
Form → Ticket Stub — A webhook that maps form fields into a ticket payload, POSTs to your tracker, and responds 201. The tracker URL is a stub; the point is the field mapping and the explicit response node.
The patterns worth stealing
Failure is a branch, not an exception
The healthcheck workflow probes URLs that are, by definition, sometimes down. A default HTTP Request node throws on a 500 and stops the execution — which means a monitoring workflow dies exactly when it has something to report.
Two settings fix that:
{
"options": {
"response": {
"response": { "neverError": true, "fullResponse": true }
}
},
"onError": "continueRegularOutput"
}
neverError turns a bad status code into data instead of an exception, fullResponse keeps statusCode available to the IF node downstream, and onError: continueRegularOutput handles the case where the request never completes at all. The unhealthy path becomes an ordinary branch in the graph, visible on the canvas, rather than a red execution in the log.
State belongs in static data, not in a database
The release watcher has to answer "have I seen this tag before?" without standing up storage for one string. n8n's per-workflow static data handles it:
const staticData = $getWorkflowStaticData('global');
const tag = $input.first().json.tag_name;
staticData.lastTag = tag;
return [{ json: { tag_name: tag, html_url: $input.first().json.html_url } }];
The IF node before it compares $json.tag_name against $getWorkflowStaticData('global').lastTag, so the first run stores the current tag quietly and only genuinely new releases get through. Static data persists across executions and is scoped to the workflow, which is exactly the lifetime a watermark wants. It is not a substitute for a real datastore once you are tracking more than a value or two, but for a high-water mark it saves you a Postgres dependency.
Secrets come from the environment
Every outbound webhook in these files reads from $env, with a harmless fallback so an unconfigured import still runs end to end instead of erroring on an empty URL:
{{ $env.ALERT_WEBHOOK_URL || 'https://httpbin.org/post' }}
That is why these templates are safe to publish and safe to commit. Set ALERT_WEBHOOK_URL or DISCORD_WEBHOOK_URL in your n8n container's environment and the same file works in development and production without edits.
The canvas is the documentation
Every template opens with a sticky note listing the two or three things you must change. It sounds trivial. It is the difference between a workflow you can hand to someone else and one only you can operate — and six months from now, you are someone else.
Fan out with splitOut, not with loops
The healthcheck stores its targets as an array and uses splitOut on the urls field to turn one item into many. Each URL then flows through the rest of the graph independently, so a single dead host produces one alert rather than aborting the batch. Reaching for a loop node here is the common instinct and the wrong one.
Adapting them
The cron expressions in these files are */5 * * * *, 0 7 * * *, and 0 */6 * * *. If you want something other than "every five minutes" or "every morning," the cron generator will show you the next five run times before you commit to an expression — which is the fastest way to catch the classic mistake of restricting both day-of-month and day-of-week, since cron treats those two fields as OR rather than AND.
When a webhook payload does not look the way you expected, paste it into the JSON formatter rather than squinting at the n8n execution log. And if you are still standing up the n8n container itself, the Docker Compose builder will get you a service definition with the volume and environment variables in the right places.
Start with one
Pick the healthcheck. It has no credentials, no external accounts, and it tells you within five minutes whether your n8n instance can reach the outside world. Once that is green, the rest of the library is variations on the same five ideas.
All six files are on the workflows page, MIT licensed, no attribution required.