Skip to main content
Altcraft Docs LogoAltcraft Docs Logo
User guideDeveloper guideAdmin guide
Company siteHelp center
English
  • Русский
  • English
v72
  • v74
  • v73
  • v72
Login
  • Getting Started
  • Administrator documentation
  • Functional characteristics
  • Technology description
  • System requirements
  • Admin Panel
  • Platform installation
  • Platform configuration
    • Configuration file
    • Domain settings
    • LDAP access configuration
    • Sending Email via SMTP relay
    • Pixel and push domain configuration
    • Cluster and Replication Setup
    • System notifications configuration
    • Processes UNIX sockets configuration
    • HTTPS Configuration
    • External SQL database integration
    • Adding sender IP addresses
    • Deduplication request settings
    • PostgreSQL database for account data
    • Proxy server settings
    • Getting HTTP service statuses
    • Configuration MongoDB logs rotation
    • Configuration of system constants and directories
  • Platform maintenance
  • Custom channels guide
  • Extra
  • Processing HTTP/HTTPS traffic
  • Administrator API
This is documentation for Altcraft Platform v72. This documentation is no longer maintained.
The information for up-to-date platform version at this page is available (v74).
  • Platform configuration
  • Getting HTTP service statuses
Documentation for version v72

Getting HTTP service statuses

Correct balancing of web services requires the user to constantly and accurately transmit the status of processes. IN order to achieve this, special API requests to process status handlers are implemented.

The status requests are as follows:

/${AK-SERVICE-NAME}/health

/${AK-SERVICE-NAME}/readiness

where ${AK-SERVICE-NAME} is a name of the platform service: webcontrol, webadmin, webapi, trkaction, trkwebctrl or cookiesaver.

List of requests​

RequestName of a serviceDescription
GET /webcontrol/healthwebcontrolChecks if the webcontrol service is running
GET /webadmin/healthwebadminChecks if the webadmin
GET /webapi/healthwebapiapiChecks if the webapiapi
GET /trkaction/healthtrkactionchecks if the trkaction
GET /trkwebctrl/healthtrkwebctrlChecks if the trkwebctrl
GET /cookiesaver/healthcookiesaverChecks if the cookiesaver
GET /webcontrol/readinesswebcontrolChecks if the webcontrol service is ready to accept traffic
GET /webadmin/readinesswebadminChecks if the webadmin service is ready to accept traffic
GET /webapi/readinesswebapiChecks if the webapi service is ready to accept traffic
GET /trkaction/readinesstrkactionChecks the trkaction service to see if it is ready to accept traffic
GET /trkwebctrl/readinesstrkwebctrlChecks the trkwebctrl service to see if it is ready to accept traffic
GET /cookiesaver/readinesscookiesaverChecks if the cookiesaver service is ready to accept traffic

Response to request​

Requests of type /health always return the code 200 with the text "OK" in the response.

If there are no problems, /readiness requests return the code 200 and the following response:

{
"status": "OK"
}

If there are any problems, the code 503 (Service not available) and the response will be returned:

{
"status": "FAIL",
"failed": ["<name of an error>"]
}

The following errors can be specified in the "failed" array:

  • started - the service startup has not been completed yet
  • mongo - the service does not have access to Mongo
  • rmq-alive - the service does not have access to RabbitMQ
  • rpc-procrpc - no RPC access to ProcRPC service or ProcRPC service does not have access to Mongo
  • rpc-proctask - no RPC access to ProcTask service or ProcTask service does not have access to Mongo
info

More information about the occured errors can be found in the logs of services.

Last updated on Aug 13, 2025
Previous
Proxy server settings
Next
Configuration MongoDB logs rotation
  • List of requests
  • Response to request
© 2015 - 2025 Altcraft, LLC. All rights reserved.