louislam/uptime-kuma

broken upside down mode with (Push) monitors' notifcation detection of important heatbeats

Ouverte

#5 911 ouverte le 13 juin 2025

Voir sur GitHubGuide contributeur
 (5 commentaires) (0 réaction) (0 personne assignée)JavaScript (7 844 forks)batch import
bughelp wanted

Métriques du dépôt

Stars
 (86 760 étoiles)
Métriques de merge PR
 (Merge moyen 6j 15h) (21 PRs mergées en 30 j)

Description

📑 I have found these related issues/pull requests

I cannot find similer problem.

🏷️ Feature Request Type

Settings, Other

🔖 Feature description

I use reversed push alert, when the script triger it, the status goes down. While the team doesn't solve the issue, the script always triger the push url . This is generate to much notification, will be a better way, if the system send only one notification for one event. So the status goes DOWN, I got only one notification while the status goes UP I got another. But now I got one notification for UP events, but millions for DOWN events.

✔️ Solution

The system send only one notification when the status changed.

❓ Alternatives

No response

📝 Additional Context

No response

Guide contributeur

Direction de recherche
Examinez la logique d'envoi des notifications, probablement dans des fichiers comme 'server/notification.js' ou similaires. Comprenez comment le système actuel détecte les changements d'état (ex. : UP/DOWN) et déclenche les notifications. Implémentez la déduplication en suivant le dernier état de notification par moniteur, en veillant à ce qu'une seule notification soit envoyée par événement DOWN jusqu'à ce que l'état change. Vérifiez les commentaires existants pour toute approche discutée ou préoccupation. Envisagez d'utiliser un indicateur de base de données ou un état en mémoire pour éviter plusieurs notifications pour le même événement.
Stack technique
javascript
Domaine
devopsobservability
Type d'issue
Fonctionnalité
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
Une demi journée
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
JavaScriptGit
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
60