--- title: Liveliness and responsiveness description: One of the simpler methods for monitoring the performance of a PingAccess deployment is determining whether the PingAccess server is available and responsive. To help you identify the status of a server, PingAccess provides a heartbeat request endpoint. component: pingaccess version: 9.1 page_id: pingaccess:pingaccess_monitoring_guide:pa_liveliness_and_responsiveness canonical_url: https://docs.pingidentity.com/pingaccess/9.1/pingaccess_monitoring_guide/pa_liveliness_and_responsiveness.html revdate: June 1, 2026 section_ids: using-the-heartbeat-endpoint: Using the heartbeat endpoint modifying-the-heartbeat-message: Modifying the heartbeat message example: Example server-metrics: Server metrics table logging-response-times: Logging response times example-2: Example --- # Liveliness and responsiveness One of the simpler methods for monitoring the performance of a PingAccess deployment is determining whether the PingAccess server is available and responsive. To help you identify the status of a server, PingAccess provides a *heartbeat request endpoint*. ## Using the heartbeat endpoint When the PingAccess server is running, sending a request to the `/pa/heartbeat.ping` endpoint (or `//pa/heartbeat.ping` if you have the **Use context root as reserved resource base path** checkbox enabled on your PingAccess application) should return an `200 OK` message. If the request times out or takes a long time to complete, the server might be overloaded or experiencing other difficulties. We recommend that you develop a baseline for the desired response time by testing the [heartbeat endpoint](../reference_guides/pa_heartbeat_endpoint.html) of your deployment at various times. This endpoint can be useful when [load balancing](../pingaccess_user_interface_reference_guide/pa_load_balancing_strategies.html) a [cluster](../reference_guides/pa_clustering_ref_guide.html) of PingAccess server instances. Some load balancers can alter the number of requests that are sent to a particular server based on the response code received, or the responsiveness of requests that are made to the heartbeat endpoint. ## Modifying the heartbeat message You can modify the output of the heartbeat to provide performance-related information, such as CPU and memory usage, along with response times. The response metrics can help you make better auto-scaling decisions. The map size metrics can help you recognize performance issues. Learn more in [Customizing the heartbeat message](customizing_the_heartbeat_message.html). ### Example The following example demonstrates the JSON response data returned after changing the `heartbeat.page.json` template file to show the memory, CPU, and response time. | | | | - | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | This example contains PingAccess server metrics available from the heartbeat endpoint. You can find more information about these metrics in the [Server metrics table](#server-metrics). | > **Collapse: Example JSON response data** > > ```json > { > "items": [ > { > "response.statistics.window.seconds": "5", > "response.statistics.count": "1", > "response.time.statistics.90.percentile": "129", > "response.time.statistics.mean": "129", > "response.time.statistics.max":"129", > "response.time.statistics.min": "129", > "response.concurrency.statistics.90.percentile": "1", > "response.concurrency.statistics.mean": "1", > "response.concurrency.statistics.max": "1", > "response.concurrency.statistics.min": "1", > "cpu.load": "15.53", > "total.jvm.memory": "500.695 MB", > "free.jvm.memory": "215.339 MB", > "used.jvm.memory": "285.356 MB", > "total.physical.system.memory": "17.18 GB", > "total.free.physical.system.memory": "278.45 MB", > "total.used.physical.system.memory": "16.901 GB", > "number.of.cpus": "8", > "hostname": "jdasilva-r", > "open.client.connections": "1", > "number.of.applications": "11", > "number.of.virtual.hosts": "6", > "last.refresh.time": "1969-12-31T18:00:00.000Z" > } > ] > } > ``` ### Server metrics table The following table describes all the PingAccess server metrics available from the heartbeat endpoint. | | | | - | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | In the following table, for server metrics that end in `.90.percentile`, the current `90` value is determined by the function calling the `ProcessingStatistics.getResponseTimePercentileMs(p, '###.##')` line in the `heartbeat.page.json` file. `90` is the default value.You can find more information on how to edit this value in step 4 of [Customizing the heartbeat message](customizing_the_heartbeat_message.html). | > **Collapse: Server metrics** > > | Server metrics | Description | > | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | > | **response.statistics.window\.seconds** | The time interval, in seconds, for the statistics report.This is an echo of the `pa.statistics.window.seconds` property's value. It provides context for the concurrency and time statistics. | > | **response.statistics.count** | The number of items considered in the heartbeat report for the time and concurrency statistics. | > | **response.time.statistics.90.percentile** | The 90th percentile response time, in milliseconds, during the statistics window\.For example, if this value is 168, then 90% of the report samples had response times below 168 milliseconds. | > | **response.time.statistics.mean** | The mean time, in milliseconds, that the PingAccess server took to respond during the statistics window. | > | **response.time.statistics.max** | The longest time, in milliseconds, that the PingAccess server took to respond during the statistics window. | > | **response.time.statistics.min** | The shortest time, in milliseconds, that the PingAccess server took to respond during the statistics window. | > | **response.concurrency.statistics.90.percentile** | The 90th percentile response concurrency during the statistics window\.For example, if this value is 124, then 90% of the report samples had response concurrency values below 124. | > | **response.concurrency.statistics.mean** | The mean number of HTTP requests that the PingAccess server processed concurrently during the statistics window. | > | **response.concurrency.statistics.max** | The maximum number of HTTP requests that the PingAccess server processed concurrently during the statistics window. | > | **response.concurrency.statistics.min** | The minimum number of HTTP requests that the PingAccess server processed concurrently during the statistics window. | > | **cpu.load** | The load on the PingAccess server's cores as a percentage of total capacity. | > | **total.jvm.memory** | The total memory of the Java Virtual Machine (JVM) *(tooltip: \
\

A virtual machine that allows a computer to run Java programs and programs that are compiled to Java bytecode.\

\
)*. | > | **free.jvm.memory** | The free memory of the JVM. | > | **used.jvm.memory** | The used memory of the JVM. | > | **total.physical.system.memory** | The total system memory. | > | **total.free.physical.system.memory** | The free system memory. | > | **total.used.physical.system.memory** | The used system memory. | > | **number.of.cpus** | The number of cores on the PingAccess server. | > | **hostname** | The host name of the system running PingAccess. | > | **open.client.connections** | The number of clients connected to PingAccess. | > | **number.of.applications** | The number of configured applications in PingAccess. | > | **number.of.virtual.hosts** | The number of configured virtual hosts in PingAccess. | > | **last.refresh.time** | Returns the time that the PingAccess configuration was last refreshed, in ISO 8601 date format. | | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | | As indicated in the table, the values of some metrics are calculated over a configurable time window. The default statistics window is zero seconds.To customize the statistics window period, change the value of the `pa.statistics.window.seconds` property in the `/conf/run.properties` file. Learn more in the [Configuration file reference](../reference_guides/pa_config_file_ref.html#pa-monitoring). | ## Logging response times By default, the audit logs record the processing time for each transaction. You can enable audit logging to identify the speed at which PingAccess processes web and API application transactions. | | | | - | -------------------------------------------------------------------------------------- | | | Depending on your logging configuration, audit logging might not log any transactions. | ### Example The following example shows an entry from the default audit log, specifically the included processing times: ```none 2019-12-15T17:23:12,192|GRmozOujPDDFct8RbtnfJw|tid:wUu9F0vDd9pZPKe4Oc5Ym_-RFCc..9r72.v8c0Y2CUA5qSpvcxKHgd7QoCp| 81 ms | 50 ms | 0 ms| servapp.ext.wal-ping.com [] /SimpleWebApi /*:3000| joe| Cookie| 127.0.0.1| GET| /SimpleWebApi/web/web.jsp| 200| | | Web-API| Root Resource| /* ``` Processing times are as follows: * Total round trip: 81 ms. Learn more in the `AUDIT.roundTripMS` audit log element. * Proxy round trip: 50 ms. Learn more in the `AUDIT.proxyRoundTripMS` audit log element. * UserInfo round trip: 0 ms. The total number of milliseconds PingAccess spent making a backchannel call to the OIDC [UserInfo endpoint](https://docs.pingidentity.com/pingfederate/13.0/developers_reference_guide/pf_userinfo_endpoint.html) and waiting for a response. A value of 0 ms indicates that a call wasn't made. Calls might be omitted on subsequent log entries. You can find more information about logging in [Log configuration](../configuring_and_customizing_pingaccess/pa_logging_configuration.html) and the elements of a log entry in [Security audit logging](../configuring_and_customizing_pingaccess/pa_security_audit_logging.html).