- Getting Started
- Swagger Definition
- Orchestrator APIs
- Alerts Requests
- Assets Requests
- Calendars Requests
- Environments Requests
- Folders Requests
- Generic Tasks Requests
- Jobs Requests
- Libraries Requests
- License Requests
- Packages Requests
- Permissions Requests
- Processes Requests
- Queue Items Requests
- Robots Requests
- Roles Requests
- Schedules Requests
- Settings Requests
- Tasks Requests
- Task Catalogs Requests
- Task Forms Requests
- Tenants Requests
- Transactions Requests
- Users Requests
- Webhooks Requests
![](https://docs.uipath.com/_next/static/media/grid.05ebd128.png?w=3840&%3Bq=100)
Health Check Endpoints
Make sure all your services are up and running by making API calls to special endpoints, called health check endpoints.
These endpoints run health checks and return a status that tells you if the service you are checking is functional or not.
To check the availability of your Orchestrator instance and its dependencies, use the following endpoints:
-
GET
https://{yourDomain}/api/health
—checks only critical dependencies -
GET
https://{yourDomain}/api/health/startup
—checks every dependency
By default, the above health check endpoints return an empty response body.
To see which health checks have been performed and the statuses they hold:
- In the
orchestrator-customconfig
config map (configured viaorchestrator-configurator.sh
), andadd<add key="HealthCheck.DetailsKey" value="12345" />
in the<appsettings>
section.12345
serves as a password which allows you to access the health checks, so do not forget to change it with a value of your own. - Restart IIS to ensure that the change takes effect.
- Use the previously set password as a query parameter in the health check API call (for example,
/api/health?detailsKey=password
). If successful, the call returns a response body containing details about the health checks and their statuses.
Once you complete these steps, the health check will also be accessible from a machine different to the Orchestrator server.
To check if the Identity Server is working, use the following endpoint:
-
GET
https://{yourDomain}/identity/health
The response body of this endpoint summarizes the Identity Server configuration.
{
"status": "Healthy",
"results": {
"ApplicationDbContext": {
"status": "Healthy",
"description": null,
"data": {}
},
"AuditDbContext": {
"status": "Healthy",
"description": null,
"data": {}
},
"PersistedGrantDbContext": {
"status": "Healthy",
"description": null,
"data": {}
},
"IdentityServerConfigurationDbContext": {
"status": "Healthy",
"description": null,
"data": {}
}
}
}
{
"status": "Healthy",
"results": {
"ApplicationDbContext": {
"status": "Healthy",
"description": null,
"data": {}
},
"AuditDbContext": {
"status": "Healthy",
"description": null,
"data": {}
},
"PersistedGrantDbContext": {
"status": "Healthy",
"description": null,
"data": {}
},
"IdentityServerConfigurationDbContext": {
"status": "Healthy",
"description": null,
"data": {}
}
}
}
A 500 error code signals an unhealthy status, however may still return a response body. Check the response body content to find out the reasons.
To check the availability of your Webhooks service, use the following endpoint:
-
GET
https://{yourDomain}/webhooks/api/status
GET/https://{yourDomain}/ResourceCatalog/health
Healthy
when the service is up and
running.