Notification Logging Reference
Summary
The service emits ten distinct log statements. Logs are JSON to console with scopes included and UTC timestamps.
Audience
DevOps engineers, engineers, support and QA.
Reference Content
The verified reference material for this topic is set out in the sections below.
Format and levels
Providers are cleared and replaced by a JSON console logger with scopes enabled, UTC timestamps and a fixed timestamp format. The default minimum level is information; the ASP.NET Core category is raised to warning.
Correlation middleware opens a scope carrying the correlation identifier and the service name, so every log line written during an HTTP request carries both.
Log statement catalog
| Level | Source | Message subject | Operational meaning |
|---|---|---|---|
| Information | Dispatcher | Duplicate event skipped, with event id and type | Idempotency working as intended — not a problem |
| Information | Dispatcher | Stale event ignored, with occurrence time | Event older than the staleness window |
| Warning | Dispatcher | Delivery failed after N attempts, with message id and channel | A message exhausted its retries and is now in the failed queue |
| Information | Email sender | Console email output | The console provider is active — nothing was actually sent |
| Information | SMS sender | Placeholder SMS output, stating no real provider is configured | Simulated delivery only |
| Information | WhatsApp sender | Placeholder WhatsApp output, stating no real provider is configured | Simulated delivery only |
| Warning | Consumer | Could not connect to the broker, naming host and port, retrying | Consumption has stopped; recurs until the broker returns |
| Information | Consumer | Bound to the queue, listing the subscribed event types | Consumption is active — the readiness signal |
| Error | Consumer | Unhandled error processing a delivery; requeueing | Infrastructure failure; the message goes back to the queue |
| Error | Consumer | Negative acknowledgement itself failed | The broker connection is failing while handling a failure |
The two lines that matter most
The bound-to-queue information line is the only positive confirmation that consumption is active. Since the health endpoint registers no checks, this log line is the sole signal that the consumer connected and subscribed. It is emitted once per successful connection.
The connect-failure warning is the only signal that consumption has stopped. It repeats on a fixed interval while the broker is unreachable. Nothing else — not health, not metrics, not the UI — reflects that state.
Both are load-bearing for operations and neither is surfaced anywhere except the log stream.
Level distribution
Six information, two warning, two error. Notably a delivery exhausting its retries is a warning, not an error — errors are reserved for infrastructure faults at the consumer boundary.
What is not logged
- No log on successful delivery, message creation or event processing completion — those are recorded in the audit trail instead, not in logs.
- No log on template resolution failure or preference suppression — again audit-only.
- No log of payload content.
- No structured event or trace identifier on most lines; correlation reaches logs only through the HTTP request scope, so broker-driven processing does not carry a correlation scope in its log lines.
That last point is significant: the richest processing path — event consumption — has the least log context.
Public-safety note
The email console sender writes rendered subject and body to the log stream, and the placeholder senders write the destination address and subject. Where the console provider or placeholders are active, notification content and recipient addresses reach the logs. This is a verified behavior of the development-default providers.
Classification
Implemented.
Requires confirmation
Whether the console email provider and placeholder senders are used in any environment where logs are retained requires confirmation.
Related Articles
See Also
Keywords
- Notification database
- Logging Reference
- Draft database documentation
Source References
microservices/src/notification-service/Application/NotificationDispatcher.csmicroservices/src/notification-service/Messaging/NotificationEventConsumer.csmicroservices/src/notification-service/Channels/EmailSenders.csmicroservices/src/notification-service/Channels/PlaceholderSenders.csmicroservices/src/notification-service/Channels/InAppSender.csmicroservices/src/shared-kernel/Extensions/ObservabilityExtensions.csmicroservices/src/shared-kernel/Middleware/CorrelationIdMiddleware.cs
Revision Information
- Status: Draft
- Last reviewed: 2026-07-21
- Review cycle: Quarterly