Din webbplats går ner och du får reda på det en timme senare. Inte för att du inte höll koll, utan för att du var upptagen med att göra faktiskt arbete i stället för att uppdatera en webbläsarflik.
Det här upplägget för Gmail driftstoppsvarningar drabbar marknadsförare under lanseringar, men byråägare och ops-fokuserade grundare känner av det också. Du får ett mejl i samma stund som din sajt slutar svara, så att du kan agera snabbt och slippa gissa.
Nedan hittar du exakt det n8n-flöde som kontrollerar din webbplats enligt schema, testar att den svarar korrekt och mejlar dig när något är fel (plus de viktigaste justeringarna för att anpassa det till din situation).
Så fungerar den här automatiseringen
Hela n8n-flödet, från trigger till slutresultat:
n8n Workflow Template: Gmail-varningar när din webbplats ligger nere
flowchart LR
subgraph sg0["Scheduled Site Poller Flow"]
direction LR
n0@{ icon: "mdi:play-circle", form: "rounded", label: "Scheduled Site Poller", pos: "b", h: 48 }
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/httprequest.dark.svg' width='40' height='40' /></div><br/>Retrieve Site Status"]
n2@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Outage Condition Check", pos: "b", h: 48 }
n3@{ icon: "mdi:message-outline", form: "rounded", label: "Dispatch Outage Email", pos: "b", h: 48 }
n2 --> n3
n1 --> n2
n0 --> n1
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 n0 trigger
class n2 decision
class n1 api
classDef customIcon fill:none,stroke:none
class n1 customIcon
Problemet: du får reda på driftstopp för sent
Driftstopp på webbplatser är stressande av en enkel anledning: det är tyst. Din startsida kan returnera fel medan du kör annonser, skickar trafik från ett nyhetsbrev eller håller en demo för en kund. Och om du inte aktivt kollar märker du det först efter att skadan redan är skedd. Än värre: manuell kontroll skapar en märklig loop av “bakgrundsoro”. Du kollar en gång. Sedan igen. Sedan undrar du om du kollade rätt sida, från rätt nätverk, vid rätt tidpunkt. Ärligt talat är det utmattande.
Det blir snabbt mycket. Här är var det brukar fallera i verkligheten.
- Du upptäcker avbrott först efter att en kund mejlar dig, vilket är det sämsta tänkbara larmsystemet.
- Manuella kontroller sker när du kommer ihåg det, inte när du behöver dem, så glapp på några timmar är vanliga.
- Små avbrott missas helt, men de kan ändå bränna annonsbudget och skada förtroendet.
- Även när du märker det slösar du tid på att bekräfta att det är på riktigt innan du agerar.
Lösningen: schemalagda webbplatskontroller + Gmail-varningar
Det här n8n-flödet gör övervakning av driftstopp till en enkel vana: kontrollera enligt schema och mejla dig bara när något ser fel ut. Det börjar med en schemalagd trigger (var 8:e timme som standard), och skickar sedan en HTTP GET-förfrågan till den URL du väljer. n8n utvärderar svaret, och om din webbplats inte returnerar HTTP 200-statusen “OK” skickas körningen vidare till en e-postnod. Mejlet landar i Gmail (eller valfri inkorg), så att varningen dyker upp där du redan jobbar. Inga dashboards att vakta. Ingen “kanske är det lugnt”-osäkerhet. Bara en tydlig signal du kan agera på.
Flödet är rakt på sak. Schemat startar, HTTP-förfrågan kontrollerar webbplatsen och ett if-villkor avgör om den är frisk. När den inte är det skickar n8n ett mejl med driftstoppsvarning till den adress du väljer, och du kan börja åtgärda problemet direkt.
Det här får du: automatisering vs. resultat
| Det här automatiserar flödet | Resultat du får |
|---|---|
|
|
Exempel: så här kan det se ut
Säg att du kör en veckovis kampanj för webbinarieanmälningar och vanligtvis kollar landningssidan cirka 6 gånger om dagen. Om varje koll tar kanske 2 minuter (öppna flik, uppdatera, klicka runt) blir det ungefär 10 minuter per dag, plus mental belastning. Med det här flödet som kör var 5:e minut under lanseringsveckan blir ditt “arbete” noll minuter. Om sidan börjar returnera något annat än 200 kommer mejlet direkt och du kan pausa annonser eller styra om trafiken innan dagen är förstörd.
Det här behöver du
- n8n-instans (testa n8n Cloud gratis)
- Alternativ för egen drift om du föredrar det (Hostinger funkar bra)
- Din webbplats-URL för HTTP-statuskontrollen.
- Gmail- eller SMTP-inkorg för att ta emot (och eventuellt skicka) varningar.
- SMTP-inloggningsuppgifter (hämta dem via Gmail-app-lösenord eller din e-postleverantör).
Svårighetsgrad: Nybörjare. Du klistrar in en URL, kopplar SMTP-uppgifter och justerar schemat.
Vill du inte sätta upp det här själv? Prata med en automatiseringsexpert (gratis 15-minuters konsultation).
Så fungerar det
En schemalagd trigger startar körningen. Som standard kontrollerar flödet var 8:e timme, men du kan ändra till var 5:e minut, varje timme eller vad som matchar hur kritisk sajten är.
n8n begär din webbplats som en besökare. Noden HTTP Request skickar en enkel GET-förfrågan till URL:en du anger och fångar svaret (inklusive statuskoden).
Sedan tas ett enkelt beslut: “frisk eller inte”. If-noden förväntar sig HTTP 200. Om sajten returnerar 500, 503, 404 eller timear ut räknas det som ett misslyckande och går vidare till varningsflödet.
Ett mejl skickas till Gmail (eller valfri inkorg). Noden Send Email använder SMTP-uppgifterna du konfigurerar i n8n, så att varningarna skickas pålitligt utan extra verktyg.
Du kan enkelt ändra schemats frekvens och logiken för “vad som räknas som nere” utifrån dina behov. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementering
Steg 1: Konfigurera schemalagd trigger
Ställ in arbetsflödet så att det pollar er webbplats enligt ett fast schema med triggernoden.
- Lägg till och öppna Scheduled Site Poller.
- Ställ in intervallregeln så att den körs var
5minut (fält: minutes, värde:5). - (Valfritt) Behåll Flowpast Branding som en visuell notering för dokumentation.
Steg 2: Anslut kontroll av webbplatsstatus
Konfigurera HTTP-förfrågan som pingar er webbplats och returnerar en statuskod.
- Lägg till och öppna Retrieve Site Status.
- Ställ in URL till
https://yourdomain.com. - Ställ in Method till
GET. - Ställ in Response Format till
json.
Steg 3: Sätt upp villkorskontroll för driftstopp
Använd en villkorskontroll för att identifiera när webbplatsen inte returnerar en korrekt statuskod.
- Lägg till och öppna Outage Condition Check.
- Under Conditions → Number, ställ in Value 1 till
={{ $json["statusCode"] }}. - Ställ in Operation till
notEqual. - Ställ in Value 2 till
200.
Körordningen går från Scheduled Site Poller → Retrieve Site Status → Outage Condition Check.
Steg 4: Konfigurera e-postaviseringar
Skicka ett e-postmeddelande när ett driftstopp upptäcks.
- Lägg till och öppna Dispatch Outage Email.
- Ställ in To Email till
[YOUR_EMAIL]och From Email till[YOUR_EMAIL]. - Ställ in Subject till
⚠️ Website Downtime Alert. - Ställ in HTML till den tillhandahållna mallen och behåll tidsstämpeluttrycket
{{$now}}i meddelandetexten.
Noden Outage Condition Check skickar lyckade matchningar direkt till Dispatch Outage Email.
Steg 5: Testa och aktivera ert arbetsflöde
Validera arbetsflödeslogiken och aktivera det för kontinuerlig övervakning.
- Klicka på Execute Workflow för att köra ett manuellt test från Scheduled Site Poller.
- Bekräfta att Retrieve Site Status returnerar en
statusCodeoch att Outage Condition Check utvärderas korrekt. - Om statuskoden inte är
200, verifiera att Dispatch Outage Email skickar ett meddelande till[YOUR_EMAIL]. - Slå på arbetsflödet Active för att starta schemalagd övervakning var 5:e minut.
Vanliga fallgropar
- SMTP-uppgifter (särskilt för Gmail) kan gå ut eller kräva särskilda inställningar. Om varningar slutar fungera: kontrollera först SMTP-credential i n8n under Credentials, och bekräfta sedan att Gmail 2FA och app-lösenord fortfarande är aktiverade.
- Om din webbplats använder omdirigeringar, underhållssidor eller botskydd kan noden HTTP Request returnera en icke-200 även när sajten “ser okej ut” i en webbläsare. Kontrollera körningsloggen för faktisk statuskod och response body.
- Standardmejl för varningar är ofta för generiska. Lägg till den kontrollerade URL:en och den returnerade statuskoden i mejltexten tidigt, annars slösar du tid på att leta upp vad som föll.
Vanliga frågor
Cirka 20 minuter om du redan har SMTP-uppgifter.
Nej. Du klistrar in din webbplats-URL, kopplar e-postuppgifter och justerar schemat.
Ja. n8n har ett gratis alternativ för egen drift och en gratis provperiod på n8n Cloud. Molnplaner startar på 20 USD/månad för högre volymer. Du behöver också räkna in begränsningar eller kostnader hos din SMTP-leverantör (Gmail är oftast gratis, medan vissa transaktions-SMTP-tjänster tar betalt baserat på volym).
Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller egen drift på en VPS. För egen drift är Hostinger VPS prisvärd och hanterar n8n bra. Egen drift ger obegränsade körningar men kräver grundläggande serverhantering.
Ja, men då vill du loopa igenom en lista med URL:er i stället för att hårdkoda en. Ett vanligt upplägg är att lagra URL:er i en enkel lista (till och med en statisk array) och använda n8n:s Loop Over Items (Split in Batches) för att köra HTTP-förfrågan för var och en. Du kan också justera Outage Condition Check så att vissa sidor tillåter omdirigeringar (301/302) medan andra måste returnera 200. Om du vill kan du även inkludera den felande URL:en och statuskoden i meddelandet i Dispatch Outage Email så att du vet exakt vad som gick sönder.
Oftast är URL:en fel, blockerad eller omdirigerar till något som noden inte kan nå. Kontrollera n8n:s körningslogg för statuskod eller timeout-meddelande, och testa sedan samma URL från maskinen som kör n8n (brandväggar och botskydd kan spela in). Om det är en skyddad endpoint, försök att övervaka en publik health-check-URL i stället.
En typisk n8n Cloud-plan klarar tusentals schemalagda kontroller per månad, och egen drift begränsas främst av din server.
Det beror på hur noga du är med kontroll och kostnad. Zapier och Make kan göra grundläggande upptidspingar, men n8n gör det enklare att förgrena logik, spara felsökningsdetaljer och köra i egen drift när du inte vill betala per task. Den stora vinsten här är tillförlitlighet och tydlighet: du kan se HTTP-statusen, det exakta svaret och beslutet som triggar varningen, allt i en och samma körning. Om du bara behöver en enkel “ping och mejl” och redan lever i Zapier kan det också fungera. Prata med en automatiseringsexpert om du vill ha hjälp att välja.
När det här väl rullar slutar driftstopp vara en gnagande oro i bakhuvudet. Du kommer bara att veta när något går sönder, och kan gå tillbaka till jobbet.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.