Du märker ofta problem med serverresurser först när något känns ”off”. Sidor blir långsamma, en jobbkök fastnar, en kund hör av sig och då börjar ritualen: SSH:a in, köra några kommandon och gissa vad som har ändrats.
Det drabbar systemadministratörer hårdast, men även en DevOps-lead som jonglerar releaser och en byråägare som hostar kundsajter känner av det. Med automation för VPS alerts email fångar du CPU-, RAM- och diskbelastning tidigt och slipper göra manuella kontroller hela dagen.
Det här arbetsflödet kontrollerar din Hostinger VPS var 15:e minut och mejlar dig när användningen passerar en tröskel. Du får se vad det övervakar, vilka resultat du kan förvänta dig och hur du anpassar det till din egen miljö.
Så fungerar den här automatiseringen
Hela n8n-arbetsflödet, från trigger till slutligt resultat:
n8n Workflow Template: E-post + Hostinger VPS-larm för CPU, RAM, disk
flowchart LR
subgraph sg0["Schedule Flow"]
direction LR
n0@{ icon: "mdi:message-outline", form: "rounded", label: "Send Email", pos: "b", h: 48 }
n1@{ icon: "mdi:cog", form: "rounded", label: "Check RAM usage", pos: "b", h: 48 }
n2@{ icon: "mdi:cog", form: "rounded", label: "Check Disk usage", pos: "b", h: 48 }
n3@{ icon: "mdi:cog", form: "rounded", label: "Check CPU usage", pos: "b", h: 48 }
n4["<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/>Merge check results"]
n5@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Check results against thresh..", pos: "b", h: 48 }
n6@{ icon: "mdi:play-circle", form: "rounded", label: "Schedule Trigger", pos: "b", h: 48 }
n3 --> n4
n1 --> n2
n1 --> n4
n2 --> n3
n2 --> n4
n6 --> n1
n4 --> n5
n5 --> n0
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 n6 trigger
class n5 decision
classDef customIcon fill:none,stroke:none
class n4 customIcon
Problemet: servern blir långsam först när det redan är för sent
Resursproblem börjar sällan med ett tydligt haveri. En VPS kan vara ”fin” vid lunch och sedan i tysthet hamna på hög CPU under en trafikspik, en backup eller ett cron-jobb som löper amok. RAM-tryck är ännu mer lömskt eftersom servern kan halta vidare medan den swappar, vilket gör att allt känns segt. Disk är den klassiska fällan: loggar växer, backuper staplas och plötsligt misslyckas deployer eller databaser slutar skriva. När du väl sitter och kontrollerar mätvärden manuellt är du redan i skadelägeshantering, och ärligt talat är det den sämsta tidpunkten att felsöka.
Det går snabbt att hamna efter. Här brukar det fallera:
- Du gör ”snabbkoll” flera gånger om dagen, och varje gång bränner du cirka 10 minuter när du väl har bytt kontext.
- Spikar händer utanför kontorstid, så du ser dem först när användare klagar eller när övervakningsgrafer ser fula ut på morgonen.
- Larm är inte konsekventa eftersom de sitter i någons huvud eller på en klisterlapp, inte i ett system.
- När flera mätvärden försämras samtidigt tappar du tid på att korrelera vad som hände först och vad som bara är en bieffekt.
Lösningen: automatiserade CPU-, RAM- och diskkontroller med e-postlarm
Det här n8n-arbetsflödet körs enligt ett schema och kontrollerar tre saker på din VPS: CPU-användning, minnesbelastning och diskanvändning. Det görs genom att ansluta via SSH och köra enkla systemkommandon (samma som du skulle köra manuellt). Därefter slår det ihop mätningarna till ett prydligt payload och utvärderar dem mot en tydlig regel: om någon mätpunkt ligger över 80 % skickas ett mejl. Inga dashboards att vakta. Inget ”jag kollar efter mötet”. Du får ett meddelande när något glider in i riskzonen, medan det fortfarande finns tid att agera.
Arbetsflödet startar var 15:e minut med en tidsstyrd trigger. Därefter kontrollerar det RAM, disk och sedan CPU, och kombinerar alla mätvärden till ett enda resultat så att ditt larmmejl innehåller hela bilden. Till sist avgör ett ”if”-villkor om tröskeln har överskridits och skickar då ett mejl till rätt inkorg.
Det här får du: automation vs. resultat
| Det här automatiserar arbetsflödet | Resultat du får |
|---|---|
|
|
Exempel: så här ser det ut i praktiken
Säg att du hanterar en Hostinger VPS som kör några kundsajter. En ”manuell kontroll” är vanligtvis tre kommandon (CPU, RAM, disk), plus att läsa output och avgöra om det är normalt, så räkna med cirka 10 minuter varje gång. Om du kollar bara 4 gånger per dag blir det ungefär 40 minuter dagligen. Med det här arbetsflödet kör triggern automatiskt var 15:e minut och skickar bara mejl när något är över 80 %, så din ”tidsåtgång” blir en snabb blick på ett larm (kanske 1 minut) istället för ständig kontroll.
Det du behöver
- n8n-instans (prova n8n Cloud gratis)
- Alternativ för egen hosting om du föredrar det (Hostinger fungerar bra)
- Hostinger VPS att övervaka CPU, RAM och disk på.
- SSH-åtkomst så att n8n kan köra serverkommandon.
- E-postuppgifter (SMTP) (hämta dem från din e-postleverantör eller din mailserver).
Kunskapsnivå: Medel. Du klistrar in SSH-uppgifter, bekräftar att serverkommandona fungerar och anger mottagaradressen för larmen.
Vill du inte sätta upp det här själv? Prata med en automationsexpert (gratis 15-minuters konsultation).
Så fungerar det
En timer drar igång. Var 15:e minut kör n8n arbetsflödet automatiskt, så att du inte behöver förlita dig på minnet eller att någon är online.
Din VPS kontrolleras via SSH. Arbetsflödet kör tre separata kontroller för minne, disk och CPU-användning. Det är lätta kommandon, men det är fortfarande riktiga avläsningar från maskinen, inte gissningar.
Siffrorna kombineras och utvärderas. Ett merge-steg samlar de tre avläsningarna på ett ställe, och sedan kontrollerar ett ”if”-villkor dem mot en 80 %-tröskel så att arbetsflödet bara eskalerar när det ska.
Ett e-postlarm skickas. När en mätpunkt överskrider gränsen får du ett meddelande som du kan vidarebefordra, arkivera eller styra in i din incidentprocess.
Du kan enkelt justera tröskeln efter din risktolerans, eller ändra schemat från 15 minuter till 5 minuter under perioder med hög trafik. Se den fullständiga implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementation
Steg 1: konfigurera schematriggern
Ställ in arbetsflödets frekvens så att resurskontroller körs automatiskt med ett fast intervall.
- Lägg till noden Timed Automation Trigger som arbetsflödets trigger.
- Ställ in Rule så att den körs var
15:e minut genom att konfigurera Interval → Minutes →15. - Koppla Timed Automation Trigger till Assess Memory Load för att starta resurskontrollerna.
Steg 2: anslut SSH-noder för resursinsamling
Konfigurera SSH-kommandona som hämtar minnes-, disk- och CPU-användning.
- Öppna Assess Memory Load och ställ in Command till
free | awk '/Mem:/ {printf "%.2f", (1 - $7/$2) * 100}'. - Inloggningsuppgifter krävs: Anslut era sshPassword-inloggningsuppgifter i Assess Memory Load.
- Öppna Inspect Disk Load och ställ in Command till
df -h | awk '$NF=="/"{printf "%.2f", $5}'. - Inloggningsuppgifter krävs: Anslut era sshPassword-inloggningsuppgifter i Inspect Disk Load.
- Öppna Gauge CPU Load och ställ in Command till
top -bn 1 | grep "Cpu(s)" | sed "s/.*, *\([0-9.]*\)%* id.*/\1/" | awk '{print 100 - $1}'. - Inloggningsuppgifter krävs: Anslut era sshPassword-inloggningsuppgifter i Gauge CPU Load.
Tips: Säkerställ att er SSH-användare kan köra free, df och top utan promptar, annars kan kommandona returnera tomma resultat.
Steg 3: konfigurera parallellt flöde för resursinsamling
Ställ in körordningen så att mätvärden samlas in och slås ihop korrekt med parallella grenar.
- Koppla Assess Memory Load så att den skickar utdata både till Inspect Disk Load och Combine Resource Metrics parallellt.
- Koppla Inspect Disk Load så att den skickar utdata både till Gauge CPU Load och Combine Resource Metrics parallellt.
- Säkerställ att Gauge CPU Load skickar utdata till Combine Resource Metrics.
⚠️ Vanlig fallgrop: Om någon av SSH-noderna inte är kopplad till Combine Resource Metrics kommer SQL-sammanslagningen att returnera saknade fält och tröskelkontrollen misslyckas.
Steg 4: kombinera och utvärdera resurströsklar
Slå ihop de tre resursmätvärdena och utvärdera om någon överskrider larmtröskeln.
- I Combine Resource Metrics, ställ in Mode till
combineBySql. - Ställ in Query till
SELECT input1.stdout as CPU, input2.stdout as Disk, input3.stdout as RAM FROM input1 LEFT JOIN input2 ON input1.name = input2.id LEFT JOIN input3 ON input1.name = input3.id. - Ställ in Number of Inputs till
3för att matcha indata för CPU, Disk och RAM. - I Evaluate Threshold Breach, konfigurera tre villkor för tal med Combine Operation inställd på
any. - Ställ in Value 1 till
={{ $json.CPU }}, Operation tilllargerEqualoch Value 2 till80. - Ställ in Value 1 till
={{ $json.Disk }}, Operation tilllargerEqualoch Value 2 till80. - Ställ in Value 1 till
={{ $json.RAM }}, Operation tilllargerEqualoch Value 2 till80.
Steg 5: konfigurera larmmejlet
Skicka ett mejl när CPU, RAM eller Disk överskrider den definierade tröskeln.
- Öppna Dispatch Alert Email och ställ in Subject till
System Resource Alert. - Ställ in To Email till
[YOUR_EMAIL]och From Email till[YOUR_EMAIL]. - Ställ in Text till
=System resources are above the threshold. CPU: {{ $json.CPU.toNumber().round(2) }}% RAM: {{ $json.RAM.toNumber().round(2) }}% Disk: {{ $json.Disk.toNumber().round(2) }}%. - Inloggningsuppgifter krävs: Anslut era smtp-inloggningsuppgifter i Dispatch Alert Email.
Steg 6: testa och aktivera ert arbetsflöde
Verifiera flödet från början till slut innan ni aktiverar automationen.
- Klicka på Execute Workflow för att köra arbetsflödet manuellt.
- Bekräfta att Combine Resource Metrics skapar fälten
CPU,RAMochDiski utdata. - Om något mätvärde är ≥
80, verifiera att Dispatch Alert Email skickar ett mejl med de formaterade värdena. - När allt fungerar, slå på arbetsflödets Active för att aktivera schemalagd övervakning.
Vanliga fallgropar
- SSH-uppgifter för Hostinger VPS kan gå ut (eller så kan root-inloggning vara avstängd). Om kontrollerna slutar fungera: verifiera SSH-åtkomst från din lokala terminal först och uppdatera sedan inloggningsuppgifterna i SSH-noden i n8n.
- Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om efterföljande noder misslyckas på grund av tomma svar.
- Standardprompter i AI-noder är generiska. Lägg in ert tonalitetsläge tidigt, annars kommer du att redigera output för alltid.
Vanliga frågor
Cirka 30 minuter om SSH- och e-postuppgifter är klara.
Nej. Du kommer mest att klistra in inloggningsuppgifter och justera ett tröskelvärde.
Ja. n8n har ett gratis alternativ för egen hosting och en gratis provperiod på n8n Cloud. Cloud-planer startar på 20 USD/månad för högre volym. Du behöver också räkna in kostnader för din e-postleverantör (oftast försumbara) och VPS-kostnaden du redan betalar.
Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller egen hosting på en VPS. För egen hosting är Hostinger VPS prisvärd och klarar n8n bra. Egen hosting ger dig obegränsat antal körningar men kräver grundläggande serveradministration.
Ja, och det är den vanligaste justeringen. Uppdatera tröskellogiken i steget ”Evaluate Threshold Breach” så att CPU, RAM eller disk använder ditt önskade värde. Många sätter CPU högre (spikar är normalt), håller disk striktare (full disk är brutalt) och skickar olika larm till olika inkorgar.
Oftast är det SSH. Bekräfta att servern tillåter SSH från IP-adressen för din n8n-host, och dubbelkolla sedan användarnamn, nyckel och port i SSH-noderna som används för CPU-, RAM- och diskkontrollerna. Säkerställ också att kontot du använder har behörighet att köra de kommandon du har konfigurerat. Om det fungerar lokalt men inte i n8n handlar det vanligtvis om en nätverksregel eller fel format på den privata nyckeln.
Med ett 15-minutersschema kör den cirka 3 kontroller per exekvering (CPU, RAM, disk), vilket blir ungefär 96 exekveringar per dag. Med n8n Cloud Starter kan du köra ett bra antal exekveringar per månad, och högre planer hanterar mer volym. Vid egen hosting finns ingen begränsning för exekveringar; det beror främst på dina serverresurser och hur många VPS-mål du lägger till.
Ofta ja, eftersom SSH-baserade kontroller och förgreningslogik passar naturligt i n8n. Zapier och Make kan fungera för enkla upplägg som ”pinga en webhook, skicka ett mejl”, men de är inte lika smidiga när du behöver köra kommandon på en server och slå ihop flera mätvärden till ett beslut. Egen hosting är den andra stora poängen: du kan köra det här hela dagen utan att oroa dig för task-prissättning. Om du vill ha en hanterad setup med låg insats och din övervakning är väldigt grundläggande kan Zapier fortfarande vara helt okej. Prata med en automationsexpert om du vill ha hjälp att välja rätt upplägg för din stack.
När det här väl rullar slutar serverkontroller att vara ett bakgrundsgöra. Du får signalen när den spelar roll och kan lägga fokus på det faktiska arbetet.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.