In PCF we can set up the health check invocation timeout to execute X seconds after the instance has been created.  But before that, let's understand the PCF Health Check Lifecycle. Stage 1: The application is deployed to PCF Stage 2: When deploying the app, a health check type is specified and optionally a timeout. If a health check type is not specified, then the monitoring process defaults to a port health check Stage 3: Cloud Controller stages, starts, and runs the application Stage 4: Based on the type specified for the app, Cloud Controller configures a health check    that runs periodically for each app instance Stage 5: When Diego starts an app instance, the app health check runs every two seconds until a response indicates that the app instance is healthy or until the health check timeout elapses. The 2-seconds health check interval is not configurable Stage 6: When an app instance becomes healthy, its route is advertised, if applicable.                  Subsequent hea

Difference between OnActionExecting and OnActionExecutingAsync Both are ActionFilters can be added as attributes on Controller methods. OnActionExecting and OnActionExecutingAsync are both called before the controller action method is executed. The difference is OnActionExecuting runs SYNCHRONOUSLY and OnActionExecutingAsync should be used when you want to run some ASYNCHRONOUS calls. OnActionExecuting Implementation public class ActionFilter : Attribute, IActionFilter { private ILoggerEntry _loggerEntry; public ActionFilter(ILoggerEntry loggerEntry) { _loggerEntry = loggerEntry ?? throw new ArgumentNullException("ILogger cannot be null"); } public void OnActionExecuted(ActionExecutedContext actionContext) { _loggerEntry.AddToLog("Called after action method executes"); } public void OnActionExecuting(ActionExecutingContext actionContext) { _loggerEntry.A

You will get this issue when you try to call the BuildServiceProvider() from the Startup.ConfigureServices method. The recommended solution is to use the IApplicationBuilder ApplicationServices to get the registered services in IServiceCollection. Calling BuildServiceProvider anywhere in your code is bad design as this might create additional singleton instances of services. Each Service provider will have its own cache of singleton instances. If multiple service builders are created in code, it will cause the singleton instances to be created more than once, which contradicts the singleton property which is only once the instance is present throughout the lifetime of the application. Please find the alternative solution below, when you want to get the registered services for dependency injection. First, create a static class with a one property IServiceProvider type public void ConfigureServices(IServiceCollection services) { services.AddScoped<ILoggerEntry, LoggerEntry>();

.Net core supports dependency injection. There are many ways that you can inject services like constructor injection, action method injection, property injection. But there will be scenarios where you need to inject dependency services to static classes. For example, injecting services to extension methods. First, create a static class with a one property IServiceProvider type public void ConfigureServices(IServiceCollection services) { services.AddScoped<ILoggerEntry, LoggerEntry>(); services.AddTransient<IMongoRepository, MongoRepository>(); } Second, configure your services in ConfigureServices() method in Startup.cs and define the lifetime of the service instance using either Transient, Scoped or Singleton types. public void ConfigureServices(IServiceCollection services) { services.AddScoped<ILoggerEntry, LoggerEntry>(); services.AddTransient<IMongoRepository, MongoRepository>(); } For the next step to configure the Static class provider proper