Basic health checks

For many apps, a basic health probe configuration that reports the app’s availability to process request is sufficient to discover the status of the app

At Startup.cs we add the following

public void ConfigureServices(IServiceCollection services)
{
	// ... other configuration
	services.AddScoped<IUserService, UserService>();

	// add health checks
	services.AddHealthChecks();
}

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
	// ... other configuration

	// map health checks to an specific endpoint
	app.UseHealthChecks("/beat");
}

This endpoint will now be available at the service’s root. If this publish f.e. at port 5000, we can now call the following endpoint

http://localhost:5000/beat

// response
status 200, Healthy

The problem with this basic check is that if something fails inside the constructor of a controller or a service, this still returns status 200, Healthy.

Controller health checks

To check for a concrete controller to see if it’s instantiating well, we may better add a /beat endpoint.

The main difference is this option will check for the contructor correctness.

[AllowAnonymous]
[HttpGet("Beat")]
public IActionResult Beat()
{
	try
	{
		return Ok($"Beat");
	}
	catch (Exception ex)
	{
		_log.LogError($"Exception captured: {ex.ToString()}");
		return StatusCode(500, ex.ToString());
	}
}

Reference(s)

https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/health-checks?view=aspnetcore-8.0
https://khalidabuhakmeh.com/health-checks-for-aspnet-core-and-entity-framework-core