Admin

Notificatiebezorging: bezorglogs voor in-app, e-mail en webpush

De pagina Notificatiebezorging laat tenant-admins zien welke notificaties zijn verwerkt, welke kanalen zijn geprobeerd en of e-mail of webpush is mislukt, gedeeltelijk gelukt of overgeslagen.

Toegang Statistieken Bezorglog Databewaking

Notificatiebezorging met kanaalstatistieken en bezorgstatussen — Het tenant-scoped overzicht van notificatiekanalen, afleverpogingen en bezorgstatussen.

1. Toegang en scope

De pagina staat onder Beheer → Notificatiebezorging.
Alle records zijn tenant-scoped en komen uit tenants/{tenantId}/notificationDeliveryLogs.
De backend geeft deze logs alleen terug aan superadmins of gebruikers met user-management permissie.
Logs tonen ontvangeridentiteit en e-mailstatus, dus deel exports of screenshots alleen met bevoegde beheerders.

2. Statistieken bovenaan

Bezorgingen

Het aantal logrecords in de huidige filter- en steekproefselectie.

Succesratio

Gebaseerd op succesvolle kanaalpogingen gedeeld door alle kanaalpogingen.

Kanaalkaarten

In-app, e-mail en webpush hebben elk eigen statuscounts, pogingen, successen en fouten.

Bronnen

Laat zien of afleverpogingen vooral uit taken, automations, directe notificaties of andere services komen.

3. Bezorglog lezen

Kolom	Betekenis
Tijd	Wanneer het delivery-service record is geschreven.
Status	Samenvatting van alle kanalen: verzonden, gedeeltelijk, mislukt of overgeslagen.
Ontvanger	Naam, e-mailadres en uid wanneer beschikbaar.
Bericht	Titel en compacte preview van de notificatie, zonder volledige payload.
In-app / e-mail / webpush	De afzonderlijke status per kanaal met tooltip voor detail en aantallen.
Resultaat	Succesvolle kanaalpogingen tegenover alle kanaalpogingen.

Gebruik de detailknop op een rij om request-id, actor, caller, ontvanger, berichtpreview en kanaaldetails te bekijken.

4. Databewaking

De delivery-service logt geen volledige e-mail MIME, bijlagen, webpush endpoints of ruwe notificatiepayloads.
De log bevat wel compacte metadata zoals titel, body-preview, bron, actor, caller, ontvanger en kanaalstatus.
Voor retentie kan Firestore TTL op createdAt worden gebruikt met een expiration offset, bijvoorbeeld zeven dagen.
Een mislukte auditlog-write blokkeert de notificatiebezorging niet; de service logt die fout server-side.
Filters op status, kanaalstatus en vrije zoektekst worden tenant-lokaal toegepast op een begrensde scan.