GitHub to Telegram, safe update alerts for your server

Your server updates shouldn’t feel like defusing a bomb. But if you’ve ever upgraded n8n mid-run, broken an integration, or realized you missed three releases, you know the mess that follows.

System administrators get hit hardest, honestly. A self-hosted n8n owner juggling client automations feels it too, and so does the small-team ops lead who “also handles servers.” This GitHub Telegram alerts automation gives you clear, step-by-step update notifications and only runs upgrades when it’s safe.

Below you’ll see how the workflow checks versions, confirms nothing critical is running, then alerts you in Telegram before and after updates. No guesswork.

How This Automation Works

The full n8n workflow, from trigger to final output:

n8n Workflow Template: GitHub to Telegram, safe update alerts for your server

Click to explore

flowchart LR

    subgraph sg0["Schedule Flow"]
        direction LR
        n0["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Get Latest Version2"]
        n1["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Code1"]
        n2["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/merge.svg' width='40' height='40' /></div><br/>Merge1"]
        n3@{ icon: "mdi:swap-horizontal", form: "rounded", label: "If1", pos: "b", h: 48 }
        n4@{ icon: "mdi:code-braces", form: "rounded", label: "Function Check Running1", pos: "b", h: 48 }
        n5["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/telegram.svg' width='40' height='40' /></div><br/>Send a text message"]
        n6["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/telegram.svg' width='40' height='40' /></div><br/>Send a text message5"]
        n7["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/telegram.svg' width='40' height='40' /></div><br/>Send a text message6"]
        n8@{ icon: "mdi:play-circle", form: "rounded", label: "Schedule Trigger1", pos: "b", h: 48 }
        n9@{ icon: "mdi:swap-horizontal", form: "rounded", label: "If3", pos: "b", h: 48 }
        n10["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/n8n.svg' width='40' height='40' /></div><br/>Get many executions1"]
        n11["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/n8nTrigger.svg' width='40' height='40' /></div><br/>n8n Trigger1"]
        n12@{ icon: "mdi:cog", form: "rounded", label: "Wait1", pos: "b", h: 48 }
        n13@{ icon: "mdi:cog", form: "rounded", label: "Execute a command2", pos: "b", h: 48 }
        n14@{ icon: "mdi:cog", form: "rounded", label: "Execute a command3", pos: "b", h: 48 }
        n3 --> n7
        n3 --> n10
        n3 --> n6
        n9 --> n14
        n9 --> n5
        n9 --> n12
        n1 --> n3
        n12 --> n10
        n2 --> n1
        n11 --> n13
        n11 --> n0
        n8 --> n13
        n8 --> n0
        n13 --> n2
        n0 --> n2
        n10 --> n4
        n4 --> n9
    end

    %% Styling
    classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
    classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
    classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
    classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
    classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
    classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
    classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    classDef disabled stroke-dasharray: 5 5,opacity: 0.5
    class n8,n11 trigger
    class n3,n9 decision
    class n0 api
    class n1,n4 code
    classDef customIcon fill:none,stroke:none
    class n0,n1,n2,n5,n6,n7,n10,n11 customIcon

The Problem: Server updates happen at the worst time

Keeping a self-hosted n8n instance current sounds simple until real life shows up. Releases drop, you get busy, and “I’ll update later” turns into “we’re four versions behind.” Then you finally upgrade and discover the timing was awful: an execution was running, a webhook was mid-flight, or a client workflow failed quietly. Even when nothing breaks, the mental load is constant. You check GitHub, check your version, check running jobs, decide when it’s safe, then hope you didn’t miss something in the release notes.

The friction compounds.

Manually comparing your n8n version to GitHub releases is easy to forget when the day gets noisy.
Upgrading while executions are running can interrupt active workflows and create “random” failures that take hours to trace.
SSH updates often get postponed because nobody wants to own the risk during business hours.
Without a clear audit trail (even just messages), you end up wondering when you last updated and what actually happened.

The Solution: Daily version checks + safe upgrades with Telegram notices

This workflow turns “keeping n8n updated” into a calm, repeatable routine. It runs daily at 9 AM (and can also run when n8n starts), checks your current n8n version via a server command, then pulls the latest release from the official n8n GitHub API. After it normalizes the version data, it compares what you have to what’s available and decides what to do next. If you’re already current, you get a simple confirmation message in Telegram. If an update exists, you get an alert, the workflow checks for running executions via the n8n API, and only then runs the upgrade command over SSH. You also get a “starting update” message and a completion confirmation, so you’re never guessing what state the server is in.

The workflow starts on a schedule (or on instance start), gathers two pieces of truth (your current version and GitHub’s latest), and compares them. If an update is needed, it waits for a safe window by checking active executions, then upgrades through SSH and reports every step in Telegram.

What You Get: Automation vs. Results

What This Workflow Automates

Results You’ll Get

It checks GitHub for the latest official n8n release automatically.
It pulls your currently installed n8n version from the server using SSH.
It queries the n8n API to see if executions are still running.
It sends Telegram notifications for “up to date,” “update available,” “update started,” and completion.

You reclaim about 30 minutes per week that would go to version checking and update decision-making.
You avoid the most common “oops” moment: upgrading while automations are mid-run.
You build an automatic update log in Telegram that’s easy to search later.
You stay current without babysitting GitHub or relying on memory.
Your updates become predictable, which makes incident response calmer.

Example: What This Looks Like

Say you manage one self-hosted n8n instance and you do a “quick check” twice a week. That’s maybe 10 minutes to check GitHub, 10 minutes to SSH in and confirm your version, and another 10 minutes to look for running executions before you even decide to upgrade. Call it about 1 hour a week. With this workflow, the daily check runs at 9 AM on its own, and you only spend time when Telegram tells you an update is available. Most weeks, your time spent is close to zero.

What You’ll Need

n8n instance (try n8n Cloud free)
Self-hosting option if you prefer (Hostinger works well)
Telegram for update alerts you’ll actually see.
GitHub API to fetch the latest n8n release.
SSH access (create credentials in n8n) to run version and upgrade commands.
n8n API credentials (generate in n8n user settings) to check running executions.

Skill level: Intermediate. You’ll paste in credentials and you should be comfortable granting SSH access to the server running n8n.

Don’t want to set this up yourself? Talk to an automation expert (free 15-minute consultation).

How It Works

A daily (or startup) trigger kicks things off. The workflow runs every day at 9 AM, and it can also run when n8n starts so you get an immediate health check after restarts.

Two version sources are collected. One SSH command retrieves the version you’re running right now, while an HTTP request pulls the newest release from the official n8n GitHub API.

The workflow compares versions and decides what’s safe. A small transformation step cleans up version strings, then an “update check” path either sends an “up to date” Telegram message or continues into an update path. If an update is available, n8n API calls retrieve the current executions list, and a function evaluates whether anything is running.

Telegram is the control tower. You get notified when an update is available, when an update is about to run, and when it finishes. If executions are running, the workflow waits and retries so updates don’t collide with live jobs.

You can easily modify the schedule time to match your quiet hours based on your needs. See the full implementation guide below for customization options.

Step-by-Step Implementation Guide

Step 1: Configure the Scheduled Trigger

Set up the time-based and init-based triggers that start the version check workflow.

Add and configure Scheduled Run Trigger with Rule set to triggerAtHour: 9.
Configure Instance Init Trigger with Events set to init so the flow also runs on startup.
Connect both triggers so Instance Init Trigger outputs to Run Version Command and Fetch Latest Release in parallel, and Scheduled Run Trigger outputs to Run Version Command and Fetch Latest Release in parallel.

If you only want scheduled checks, you can disable Instance Init Trigger and keep Scheduled Run Trigger active.

Step 2: Connect Version Data Sources

Pull the current n8n version from your server and the latest release from GitHub.

Configure Run Version Command with Command set to n8n -v.
Credential Required: Connect your SSH credentials in Run Version Command to access the host.
Configure Fetch Latest Release with URL set to https://api.github.com/repos/n8n-io/n8n/releases/latest.
Route both nodes into Combine Inputs so the merge output feeds Transform Version Data.

⚠️ Common Pitfall: Ensure the SSH user has permission to run n8n -v on the target system, or the version check will fail.

Step 3: Set Up Version Comparison Logic

Normalize version strings and determine if an update is available.

In Transform Version Data, keep the provided JavaScript Code to normalize versions and set updateAvailable.
Configure Version Update Check to evaluate Boolean condition Left Value set to ={{ $json.updateAvailable }}.
Confirm that Version Update Check routes the true branch to both Notify Update Available and Retrieve Executions List in parallel.
Confirm the false branch routes to Notify Up To Date.

Parallel execution matters here: Version Update Check outputs to both Notify Update Available and Retrieve Executions List in parallel, so notifications and eligibility checks happen simultaneously.

Step 4: Configure Update Eligibility and Retry Logic

Check for running executions and gate updates to avoid collisions.

In Retrieve Executions List, keep Resource set to execution.
Credential Required: Connect your n8n credentials in Retrieve Executions List to access execution data.
In Assess Running Jobs, keep the Function Code that sets canUpdate based on running executions.
Configure Update Eligibility Check with Left Value set to ={{ $json.canUpdate }}.
Set Delay Before Retry with Unit set to minutes and route its output back to Retrieve Executions List for re-checks.

⚠️ Common Pitfall: If the retry delay is too short, frequent polling may overload your n8n instance.

Step 5: Configure Update Actions and Notifications

Notify stakeholders and run the upgrade when it is safe.

Configure Notify Update Available with Text set to =Tienes una actualización de n8n and Chat ID set to [YOUR_ID].
Configure Notify Up To Date with Text set to =Tu n8n esta en la ultima version. v{{ $json.latest }} and Chat ID set to [YOUR_ID].
Configure Notify Update Start with Text set to Se va a proceder a actualizar n8n and Chat ID set to [YOUR_ID].
Credential Required: Connect your Telegram credentials in Notify Update Available, Notify Up To Date, and Notify Update Start.
Configure Run Upgrade Command with Command set to sudo npm update -g n8n && sudo systemctl restart n8n.
Credential Required: Connect your SSH credentials in Run Upgrade Command to perform the upgrade.
Confirm Update Eligibility Check outputs to both Run Upgrade Command and Notify Update Start in parallel.

⚠️ Common Pitfall: The SSH user must have permission to run sudo npm update -g n8n and restart the service.

Step 6: Test and Activate Your Workflow

Validate the automation end-to-end and turn it on for production use.

Click Execute Workflow to run a manual test from Scheduled Run Trigger or Instance Init Trigger.
Verify that Run Version Command and Fetch Latest Release execute in parallel and merge into Combine Inputs.
Confirm successful runs: if no update is available, Notify Up To Date sends the version message; if an update is available, Notify Update Available fires and the workflow proceeds through eligibility checks.
When canUpdate is true, confirm Run Upgrade Command and Notify Update Start run in parallel.
Toggle the workflow to Active to enable scheduled and init-based monitoring.

🔒

Unlock Full Step-by-Step Guide

Get the complete implementation guide + downloadable template

Common Gotchas

SSH credentials can expire or need specific permissions. If things break, check your server user permissions and the n8n Credentials screen first.
If you’re using Wait nodes or external rendering, processing times vary. Bump up the wait duration if downstream nodes fail on empty responses.
Telegram bot credentials can be correct but still “fail” because the chat ID or message thread ID is wrong. Check the Telegram node configuration and confirm the bot can post in that chat.

Frequently Asked Questions

How long does it take to set up this GitHub Telegram alerts automation?

About 30 minutes if you already have SSH and Telegram credentials ready.

Do I need coding skills to automate GitHub Telegram alerts?

No. You’ll mostly connect credentials and adjust a couple of values like chat ID and schedule time.

Is n8n free to use for this GitHub Telegram alerts workflow?

Yes. n8n has a free self-hosted option and a free trial on n8n Cloud. Cloud plans start at $20/month for higher volume. You’ll also need to factor in Telegram (free) and your server/VPS costs.

Where can I host n8n to run this automation?

Two options: n8n Cloud (managed, easiest setup) or self-hosting on a VPS. For self-hosting, Hostinger VPS is affordable and handles n8n well. Self-hosting gives you unlimited executions but requires basic server management.

Can I customize this GitHub Telegram alerts workflow for Docker-based updates?

Yes, but you’ll change the SSH “upgrade” command to match your setup. Many Docker users replace the upgrade step with something like pulling n8nio/n8n:latest and restarting the container. You can also tweak the Schedule Trigger time and adjust the Telegram message text so it matches your internal change process.

Why is my Telegram connection failing in this workflow?

Usually it’s the credential itself (wrong bot token) or the bot can’t post in the target chat. Regenerate the Telegram bot token if needed, then confirm the chat ID is correct and the bot has permission to send messages there. If you’re posting into a forum topic, a wrong message thread ID can also cause silent failures.

How many executions can this GitHub Telegram alerts automation handle?

A daily check is tiny, so volume is rarely the limiter. On n8n Cloud Starter you get a fixed monthly execution allowance, and this workflow typically uses a handful of executions per day. If you self-host, there’s no execution cap; it mainly depends on your server resources and how often you schedule checks.

Is this GitHub Telegram alerts automation better than using Zapier or Make?

For server update workflows, n8n is usually the better fit because it can run self-hosted and it handles branching logic without making every path a paid “task.” More importantly, Zapier and Make aren’t designed for safely running SSH commands and checking internal n8n execution state, which is the whole point here. If you only want a simple “new GitHub release → send message” alert, those tools can work fine. But the safety checks and retries are where n8n shines. Talk to an automation expert if you want help choosing.

Once this is running, updates stop being a recurring “someday” task and become a quiet background check. The workflow handles the repetitive parts so you can focus on what your automations are supposed to do.

GitHub to Telegram, safe update alerts for your server

How This Automation Works

n8n Workflow Template: GitHub to Telegram, safe update alerts for your server

The Problem: Server updates happen at the worst time