Uptime Kuma skickar inte aviseringar: orsaker och lösningar

När Uptime Kuma skickar inga aviseringarProblemet ligger inte alltid i Telegram, e-postservern eller webhooken. Det kan också vara att kanalen inte är kopplad till övervakaren, att det inte har skett någon faktisk statusändring ännu, eller att återförsök fördröjer varningen.

Det bästa sättet att lösa detta är att kontrollera varje del av kedjan separat: först kanalen, sedan dess koppling till övervakaren och slutligen anslutningen från servern eller containern där Uptime Kuma körs. Om du fortfarande konfigurerar övervakarna kan du hänvisa till detta. Allmän guide för Uptime Kuma.

Börja med att identifiera var aviseringen misslyckas.

Innan du ändrar lösenord, portar eller certifikat, kontrollera exakt vad som händer. Här är de vanligaste scenarierna:

Symptom	Trolig orsak	Första kontrollen
Det manuella testet misslyckas	Inloggningsuppgifter, adress, nätverk eller TLS	Granska leverantörens konfiguration
Testet fungerar, men den riktiga varningen kommer inte.	Kanal inte associerad eller övervakad utan statusändring	Redigera monitorn och granska dina aviseringar
Endast en skärm är trasig.	Felaktig individuell konfiguration	Jämför den med en annan bildskärm som varnar dig
Aviseringen tar för lång tid.	Återförsök eller för långt intervall	Kontrollera bildskärmsinställningarna
Uptime Kuma indikerar framgång, men du ser inte meddelandet	Skräppost, fel mottagare eller avstängd app	Kontrollera den mottagande tjänsten

Denna klassificering undviker att ändra flera alternativ samtidigt och gör det enklare att lokalisera felet utan att skada en konfiguration som redan delvis fungerar.

Hur man testar aviseringskanalen

Öppna Inställningar > AviseringarVälj den problematiska kanalen och tryck på knappen TestaUptime Kuma kommer att försöka skicka ett meddelande med den angivna konfigurationen.

Om testet misslyckas ger meddelandet som visas vanligtvis en ledtråd:

• Obehörig eller 401: Token, användarnamn eller lösenord är ogiltigt.
• Förbjudet eller 403: Autentiseringsuppgifterna finns, men de har inga behörigheter.
• Inte hittad eller 404: Webhooken eller resursadressen är felaktig.
• För många förfrågningar eller 429: Leverantören har tillämpat en tidsgräns.
• INTE HITTAD: Servern kan inte matcha domänen med DNS.
• TIMEDOUT: Anslutningen blockeras eller får inget svar.
• Certifikatfel: Certifikatet är ogiltigt, har gått ut eller matchar inte domänen.

Ett lyckat test bekräftar att Uptime Kuma kan kontakta leverantören vid den tidpunkten. Emellertid, Det bevisar inte att aviseringen är aktiverad på skärmen inte heller att en faktisk `DOWN`- eller `UPP`-händelse har genererats.

Kontrollera att aviseringen är länkad till monitorn

Detta är ett av de vanligaste felen. Kanalen kan vara perfekt konfigurerad och klara testet, men gör ingenting eftersom ingen monitor använder den.

1. Öppna monitorn som inte skickar varningar.
2. Trycka Redigera.
3. Leta efter avsnittet Aviseringar.
4. Aktivera den kanal du vill använda.
5. Spara ändringarna.

Alternativet Standardaktiverad Detta gör att en avisering kan väljas som standard när nya övervakare skapas. Samtidigt, Tillämpa på alla befintliga bildskärmar Det kan tillämpas på befintliga bildskärmar.

Även när du använder dessa alternativ är det lämpligt att öppna en av de berörda bildskärmarna och manuellt verifiera att kanalen är vald. Detta är särskilt viktigt när det finns flera aviseringar med liknande namn.

Verifiera att det faktiskt sker en tillståndsförändring

Uptime Kuma skickar viktiga varningar när monitorn ändrar status. Om den kontinuerligt förblir i "UPP" eller "NER" kan inga ytterligare varningar utfärdas om du inte har konfigurerat påminnelser eller vidarebefordran.

Du bör också kontrollera antalet försöker igen innan tjänsten markeras som nereOm övervakaren kontrollerar tjänsten var 60:e sekund och har tre nya försök, kommer varningen inte att utlösas av det första felet. Uptime Kuma väntar tills de nödvändiga villkoren är uppfyllda för att ändra statusen till "NED".

För att verifiera hela flödet utan att avbryta en aktiv tjänst kan du skapa en tillfällig övervakare som pekar på en stängd port. Vänta tills den ändras till `DOWN`, bekräfta mottagandet av meddelandet och ändra sedan övervakaren för att använda en tillgänglig tjänst. Du bör också få `UP`-återställningen.

Om du behöver övervaka innehåll och inte bara HTTP-kod kan du Övervaka en webbplats med Uptime Kuma med hjälp av lämplig verifiering.

Uptime Kuma skickar inte e-post via SMTP

När e-post misslyckas, kontrollera först kombinationen mellan port och krypteringEn felaktig konfiguration kan förhindra anslutningen även om användarnamnet och lösenordet är giltiga.

Hamn	Standardkonfiguration
465	TLS implicit från början av anslutningen
587	Initial anslutning följt av STARTTLS
25	Det beror på servern; den kan vara blockerad av leverantören.

Kontrollera även följande punkter:

• El SMTP-servernamn Den måste exakt matcha den som tillhandahålls av tjänsten.
• Användarnamnet är vanligtvis den fullständiga e-postadressen, även om det beror på leverantören.
• Konton som skyddas med MFA kan behöva en applikationslösenord.
• Avsändarens adress måste vara auktoriserad av servern.
• Mottagaren måste stavas korrekt.
• Ytterligare rubriker måste innehålla giltig JSON om du väljer att använda dem.
• Certifikatet måste vara giltigt och matcha den konfigurerade domänen.

Det är inte lämpligt att permanent aktivera ett alternativ för Ignorera TLS-felDet kan fungera som ett engångstest för att identifiera ett felkonfigurerat internt certifikat, men det minskar säkerheten och löser inte orsaken till problemet.

Om Uptime Kuma indikerar att meddelandet har skickats kontrollerar den skräppostmappen, e-postreglerna och e-postserverloggarna. Vissa tjänster accepterar först meddelandet och blockerar det sedan eftersom avsändaren bryter mot deras policyer.

Uptime Kuma skickar inte meddelanden via Telegram

För att korrekt konfigurera Kuma-aviseringar om drifttid via Telegram Du behöver en giltig bottoken och den exakta chatt-ID:n.

• Kontrollera att token inte innehåller mellanslag eller extra tecken.
• Starta en konversation med boten och skicka ett meddelande innan du testar den.
• Om du använder en grupp, lägg till boten och ge den behörighet att posta.
• Kom ihåg att gruppidentifierare vanligtvis innehåller ett negativt värde.
• Om gruppen använder teman, konfigurera Meddelandetråds-ID motsvarande.
• Kontrollera om alternativet för tyst meddelande är aktiverat.

Det är också möjligt att Telegram är avstängt på telefonen. I så fall kommer meddelandet fram korrekt, men enheten visar inget ljud eller en popup-avisering.

Om du vill separera kritiska meddelanden från vanliga varningar finns det en annan möjlighet konfigurera NTFS som en extra kanal och ha en reservväg.

Webhooks för Discord, Slack eller andra tjänster misslyckas

En webhook ska peka på mottagande slutpunkt som tillhandahålls av tjänstenDet fungerar inte om du anger en vanlig kanaladress, en inställningssida eller en URL som kopierats från din webbläsare.

Om leveransen misslyckas, kontrollera:

• Att webhooken inte har raderats, återkallats eller återskapats.
• Se till att URL:en är komplett och inte innehåller mellanslag.
• Servern bör acceptera förfrågningar från Uptime Kuma-adressen.
• Se till att autentiseringsrubrikerna är korrekta.
• Se till att den skickade brödtexten har det förväntade JSON-formatet.
• Att det inte finns någon tidsgräns för förfrågningar.

När du använder en webhook i en automatisering, testa först slutpunkten med en enkel arbetsbelastning. Sedan kan du använda den för mer avancerade åtgärder, till exempel starta om en Docker-container automatiskt efter ett bekräftat fall.

Kontrollera nätverket från Uptime Kuma-behållaren

Bara för att Telegram, Gmail eller en webhook fungerar från din dator betyder det inte att de är tillgängliga från containern. Uptime Kuma, som måste matcha domänen och upprätta den utgående anslutningen.

Först, leta reda på containernamnet:

docker ps

Om det kallas uptime-kumaDu kan kontrollera DNS-upplösningen med hjälp av:

docker exec uptime-kuma node -e "require('dns').lookup('api.telegram.org', console.log)"

Så här testar du en HTTPS-anslutning från samma container:

docker exec uptime-kuma node -e "fetch('https://api.telegram.org').then(r => console.log(r.status)).catch(console.error)"

Ersätt domänen med SMTP-servern, webhooken eller API:et som du diagnostiserar. De vanligaste felen indikerar följande:

• INTE HITTAD: Felaktig DNS-konfiguration.
• EHOSTUNREACH: Det finns ingen väg till destinationen.
• TIMEDOUT: En brandvägg, proxy eller fjärrtjänst blockerar anslutningen.
• EKONOMISK AVVISAD: Porten är stängd eller så lyssnar inte tjänsten.
• Certifikatet har gått ut: Servercertifikatet har gått ut.

I företagsnätverk kan det också vara nödvändigt att konfigurera en Docker-utdataproxy eller installera den interna certifikatutfärdaren i miljön som kör Uptime Kuma.

Kontrollera proxy, DNS, certifikat och tid

Felaktig systemtid kan ogiltigförklara tillfälliga certifikat eller tokens. Kontrollera att värden håller sin klocka synkroniserad med NTP och att containern ärver en konsekvent tidskonfiguration.

Om du använder en företagsproxy, kontrollera att den tillåter anslutningar till de domäner och portar som används av aviseringarna. Vissa proxyservrar accepterar normal webbtrafik men blockerar SMTP-anslutningar eller webhooks till obehöriga destinationer.

I installationer med interna certifikat måste Uptime Kuma lita på den utfärdande myndigheten. Att inaktivera certifikatverifiering urskillningslöst maskerar bara problemet och kan underlätta man-in-the-middle-attacker.

Återförsök, pauser och underhåll kan dölja aviseringar.

En pausad övervakare utför inga kontroller, så den kan inte generera en tillståndsändring. Kontrollera att den visas som aktiv innan du undersöker vidare.

De underhållsfönster De är utformade för att förhindra varningar vid planerade avbrott. Kontrollera att monitorn inte ingår i aktivt eller schemalagt underhåll med felaktig tidszon.

Återförsök kan också få det att se ut som om meddelandet har misslyckats. I verkligheten väntar Uptime Kuma fortfarande på ytterligare kontroller innan avbrottet deklareras. Justera detta värde för att hitta en balans mellan hastighet och skydd mot falska positiva resultat.

Så här granskar du Kuma Uptime-loggar

Om gränssnittet inte förklarar felet tillräckligt noggrant, kontrollera containerloggarna:

docker logs --tail 200 uptime-kuma

Så här visar du nya meddelanden medan du kör ett test:

docker logs --follow --tail 200 uptime-kuma

Om du använder Docker Compose och tjänsten anropas uptime-kumaDu kan också köra:

docker compose logs --tail=200 uptime-kuma

Leta efter referenser till leverantörsnamnet, HTTP-koder, autentiseringsfel, DNS-problem, timeouts eller avvisade certifikat. Publicera inte fullständiga loggar utan att granska dem: de kan innehålla interna adresser, mottagare eller delar av inloggningsuppgifterna.

Vanliga misstag när du konfigurerar aviseringar

Testet fungerar, men fallet genererar ingen varning.

Kanalen är förmodligen inte aktiverad på den skärmen, eller så har antalet återförsök inte uttömts ännu. Redigera skärmen, kontrollera de valda aviseringarna och vänta på en faktisk ändring till 'NER'.

Du får återställningsmeddelandet, men inte nedgångsmeddelandet.

Granska de aktiverade händelserna, filtren för den mottagande tjänsten och loggarna som motsvarar den exakta tidpunkten för avbrottet. Det första meddelandet kan också ha filtrerats som skräppost eller blockerats tillfälligt.

Endast en skärm fungerar inte.

Jämför dess konfiguration med en annan enhet som fungerar. Kontrollera den tillhörande kanalen, återförsök, underhållsfönster och om övervakaren är pausad.

Aviseringar slutade fungera efter en uppdatering

Kör testet igen, kontrollera loggarna och verifiera att autentiseringsuppgifterna, variablerna och certifikaten fortfarande finns tillgängliga i containern. Kontrollera även versionsinformationen innan du ändrar konfigurationen.

E-postmeddelandena skickas, men de anländer utan den förväntade ämnesraden.

Använd helst den inbyggda SMTP-leverantören och granska ämnesradsmallen. Om du har lagt till anpassade rubriker, se till att de bildar ett giltigt JSON-objekt och inte skriver över viktiga fält.

Rekommenderad ordning för att lösa problemet

1. Presstest i kanalinställningarna.
2. Korrigera autentiseringsuppgifterna, slutpunkten eller krypteringen. om testet misslyckas.
3. Kontrollera att kanalen är aktiverad på den berörda skärmen.
4. Kontrollera om det finns omförsök, pauser och schemalagt underhåll.
5. Den utlöser ett kontrollerat fall för att verifiera händelserna `NER` och `UPP`.
6. Kontrollera DNS och anslutning från containern.
7. Kontrollera loggarna under ett nytt test.
8. Konfigurera en andra kanal för att ha redundanta aviseringar.

När Uptime Kuma skickar inga aviseringarLösningen innebär att avgöra om felet ligger hos leverantören, kopplingen till monitorn, händelsegenereringen eller containernätverket. Ett lyckat manuellt test är bara det första steget: du måste också bekräfta att monitorn ändrar tillstånd och att den mottagande tjänsten accepterar och visar meddelandet.

När varningarna är återställda är det lämpligt att upprätthålla minst två separata kanaler, som Telegram och e-post. På så sätt kommer ett engångsproblem med en leverantör inte att lämna dig helt oförberedd på ett avbrott.