Automatische Event-basierte Alerts
ID: PA-002 · Service: push-alerts · Status: 🟢 aktiv · Use Case: UC-PA-004, UC-PA-005
Das Backend prüft regelmäßig definierte Bedingungen anderer Services und sendet Push-Nachrichten, wenn eine Bedingung erfüllt ist und der Benutzer die zugehörige Regel aktiviert hat. Neue Trigger-Typen können ohne Plattformänderung registriert werden (Erweiterungspunkt via Trigger-Registry).
Typ
functional
Trigger Registry
Lunch Missing Order
| Feld | Wert |
|---|---|
| Service | lunch |
| Beschreibung | Kein Mittagessen für einen aktiven Account in den nächsten 2+ Wochen. Wird einmal täglich geprüft. Pro fehlenden Account eine separate Push-Nachricht. |
| Pruef Zeitpunkt | täglich 07:00 Uhr |
| Titel Template | 🍽️ Mittagessen fehlt – |
| Body Template | Für {account_name} sind in 2+ Wochen keine Bestellungen vorhanden. |
| Url | /lunch |
| Deduplizierung | max. 1 Alert pro Account pro Tag |
Trading Data Stale
| Feld | Wert |
|---|---|
| Service | trading-data-layer |
| Beschreibung | Der Data Layer hat seit mehr als 2 Stunden keine neuen Forex-Daten gesammelt (möglicher API-Ausfall oder Verbindungsfehler). |
| Pruef Zeitpunkt | stündlich |
| Titel Template | ⚠️ Trading-Daten veraltet |
| Body Template | Der Data Layer hat seit {hours}h keine neuen Daten gesammelt. |
| Url | /trading/data-layer |
| Deduplizierung | max. 1 Alert alle 4 Stunden |
System Service Down
| Feld | Wert |
|---|---|
| Service | platform |
| Beschreibung | Ein Health-Check eines überwachten Services schlägt fehl. |
| Pruef Zeitpunkt | alle 15 Minuten |
| Titel Template | 🔴 Service nicht erreichbar – |
| Body Template | {service_name} antwortet nicht. Letzter Check: {timestamp}. |
| Url | /system |
| Deduplizierung | max. 1 Alert pro Service alle 30 Minuten |
Scheduling
Engine: APScheduler (im Backend-Container)
Jobs
| ID | Cron-Ausdruck |
|---|---|
| alert_lunch_check | 0 7 * * * |
| alert_data_stale_check | 0 * * * * |
| alert_system_health_check | */15 * * * * |
Deduplizierung
| Feld | Wert |
|---|---|
| Beschreibung | Vor dem Versand wird geprüft, ob für denselben Benutzer + Trigger-Key innerhalb des Deduplizierungsfensters bereits ein Alert gesendet wurde. Ist das der Fall, wird der Versand übersprungen (Status: skipped). |
| Implementierung | alert_history Tabelle (gesendete Alerts der letzten 24h) |
API
Endpoints
| Methode | Path | Beschreibung | Auth |
|---|---|---|---|
| GET | /api/alerts/triggers | Liste aller verfügbaren Trigger-Typen mit Beschreibung | required |
| GET | /api/alerts/rules?type=automatic | Aktive automatische Regeln des Benutzers | required |
| PUT | /api/alerts/rules/{trigger_key}/toggle | Automatische Regel aktivieren / deaktivieren | required |
Abnahmekriterien
- [ ] Lunch-Alert wird täglich um 07:00 geprüft und bei fehlenden Bestellungen gesendet
- [ ] Pro Trigger-Key + Benutzer max. ein Alert im konfigurierten Zeitfenster (Deduplizierung)
- [ ] Benutzer kann jeden Trigger-Typ individuell aktivieren / deaktivieren
- [ ] Versand und Status werden in alert_history persistiert
- [ ] Neuer Trigger-Typ kann durch Hinzufügen zur Trigger-Registry aktiviert werden
Depends On
- PA-001
- AUTH-001
Changelog
Eintrag 1
Version: 1.0
Changes: Initiale Version