Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/nimanikoo/Dotnet-RateLimiter/llms.txt

Use this file to discover all available pages before exploring further.

Dotnet-RateLimiter ships with a built-in health monitoring system powered by AspNetCore.HealthChecks. It exposes a machine-readable JSON endpoint for polling and a visual browser dashboard so you can see — at a glance — whether Redis is reachable and your application is alive. Both endpoints are registered automatically when you call AddCustomRateLimiter.

​
Available Endpoints

EndpointDescription
GET /healthRaw JSON health status consumed by HealthChecks UI
GET /health-uiVisual browser dashboard at the configured UIPath
The /health endpoint uses UIResponseWriter.WriteHealthCheckUIResponse so the JSON structure is understood directly by the HealthChecks UI library without any extra configuration.

​
What Is Monitored

​
Redis Server connectivity

The Redis instance is registered as a named health check with the tag set ["db", "cache", "redis"]. The check opens a test connection to the configured Redis endpoint on every evaluation cycle and reports Healthy, Degraded, or Unhealthy based on the result.

​
System liveness

The .NET runtime liveness check verifies that the application process itself is responsive. This is surfaced alongside the Redis check in the dashboard.

​
Evaluation interval

The UI polls the /health endpoint every 5 seconds, so the dashboard reflects the current state within one polling cycle.

​
Data source endpoint

http://localhost:8080/health
This is the address the HealthChecks UI uses to fetch status data. It matches the port exposed by the api container in compose.yaml.

​
Registration Code

​
RateLimiterExtensions.cs — service registration

services.AddHealthChecks()
    .AddRedis(
        redisConnectionString: configuration.GetSection("Redis:ConnectionString").Value!,
        name: "Redis Server",
        tags: ["db", "cache", "redis"]
    );

services.AddHealthChecksUI(settings =>
{
    settings.AddHealthCheckEndpoint("Main App", "http://localhost:8080/health");
    settings.SetEvaluationTimeInSeconds(5);
}).AddInMemoryStorage();

​
Program.cs — middleware and route mapping

app.MapHealthChecks("/health", new HealthCheckOptions
{
    ResponseWriter = UIResponseWriter.WriteHealthCheckUIResponse
});

app.UseHealthChecksUI(config =>
{
    config.UIPath = "/health-ui";
});
Both pieces are required: MapHealthChecks exposes the raw JSON endpoint, and UseHealthChecksUI mounts the visual dashboard at /health-ui.

​
Storage

The health check history is stored in-memory using .AddInMemoryStorage(). This means the UI is available immediately with zero external dependencies — no extra database, no extra container.
In-memory storage is erased on every application restart and is not suitable for production observability. For production deployments, replace .AddInMemoryStorage() with a persistent provider such as .AddSqliteStorage() or .AddPostgreSqlStorage() so that historical health data survives process restarts.

​
Fail-Fast Behavior

When Redis becomes unreachable, the Redis Server health check immediately transitions to Unhealthy. This is visible in the /health-ui dashboard and the /health JSON response within one evaluation interval (≤ 5 seconds). Because the health endpoint returns a non-200 HTTP status code when any registered check is Unhealthy, load balancers and Kubernetes liveness/readiness probes can remove the instance from rotation automatically. This integrates cleanly with circuit-breaker patterns: an upstream proxy can stop routing traffic to an instance that reports an unhealthy Redis connection, preventing cascading failures under a Redis outage.

Build docs developers (and LLMs) love

Get started for freeTalk to us