Notification Health Endpoints
Summary
Program.cs registers the health-checks service and maps a single endpoint, GET /health, tagged health. The registration adds no individual checks.
Audience
DevOps engineers, engineers, architects, QA and support.
Reference Content
The verified reference material for this topic is set out in the sections below.
GET /health
Mapped through MapHealthChecks("/health"). Because AddHealthChecks() is called without any subsequent check registration, the endpoint reports on an empty check set and returns the framework default response — a plain-text overall status — rather than a structured per-dependency report.
Declared authentication and authorization: none.
What is not checked
The reviewed registration includes no database check, no broker or connection check, no hosted-consumer liveness check and no channel-provider check. A healthy response therefore confirms that the HTTP host is accepting requests; it does not confirm that the database is reachable, that the event consumer is subscribed, or that any channel sender is functional.
This distinction matters for anyone wiring the endpoint to an orchestrator probe.
Separate readiness and liveness
There is no separate readiness endpoint, no liveness endpoint, no tag-filtered health route and no health-check UI registration. /health is the only health route.
Relationship to service information
GET / returns service identity and environment metadata and is documented separately in service information. It is not a health check and performs no dependency probing.
Classification
Partial — the endpoint is implemented, the check set is empty.
Requires confirmation
Whether dependency checks are planned, and which probe an orchestrator is expected to consume, require confirmation.
Related Articles
See Also
Keywords
- Notification API
- Health Endpoints
- Draft API documentation
Source References
microservices/src/notification-service/Program.cs
Revision Information
- Status: Draft
- Last reviewed: 2026-07-21
- Review cycle: Quarterly