Skip to main content

Monitoring

Nexus provides health checks, instance heartbeats, job-run logs/progress, queue statistics, and OpenTelemetry metrics. Use health checks for the current operational status and metrics for throughput and timing over time.

Health checks​

Jobs, queues, and functions register health checks with Nexus. When the API's RegisterHealthChecksAsAspNetCoreHealthChecks option is enabled (the default), an ASP.NET Core host can expose them through:

app.MapHealthChecks("/health");

Job failures, long-running jobs, failed functions, and queue errors are visible in the Admin UI. Job and queue attributes/metadata can customize the health status used for failures. Historical transitions are available through health-check statistics.

For custom checks, non-web hosts, and publishers, see health-check configuration. Publishers needing scoped Nexus dependencies should use AddScopedHealthCheckPublisher<T>(); see dependency injection. Teams and Slack integrations publish failures and recovery notifications.

Heartbeats​

Nexus reports instance heartbeats so other hosts can distinguish active instances from ones that have stopped reporting. INexusInstanceHeartbeatService in CommerceMind.Nexus.Abstractions.Core.Heartbeats exposes GetNexusInstanceStatusesAsync() for inspection.

Keep INexusInstance.InstanceId stable and unique among concurrently running instances. Heartbeats and startup resets help recover jobs/functions left running after a crash. They do not undo application side effects; inspect an interrupted operation before retrying it when repetition could matter. See hosting.

Queue readiness and distributed workers​

A queue can contain pending messages while processing is disabled, paused on error, waiting for activation delay, or waiting for a cron schedule. Queue activation state is separate from message count and job-run state. See queue activation.

External pending providers register NexusExternalQueueReadiness_{ProviderId} health checks. An unhealthy bridge can prevent prompt starts even while the broker retains the messages. Verify topology, subscriptions/groups, and access permissions as described in external pending storage.

Distributed processors do not create job runs. Inspect their queue's Processing tab or /api/queues/{queueName}/processor for active workers, in-flight messages, instance reports, and recent errors. These controls and processing settings belong to the new Admin UI. Message counters include queue.name to distinguish queues sharing an implementation.

Queue statistics describe status transitions, not current backlog. The API omits queue counts unless requested; missing counts do not mean zero messages. Combine counts, error status, leases, and worker activity when diagnosing processing delays.