This is an automated email from the ASF dual-hosted git repository.
potiuk pushed a commit to branch v3-1-test
in repository https://gitbox.apache.org/repos/asf/airflow.git
The following commit(s) were added to refs/heads/v3-1-test by this push:
new 026236eab00 [v3-1-test] [DISCUSSION-54853] Update webserver probe
health check doc (#59942) (#59982)
026236eab00 is described below
commit 026236eab0052bb2d78304b588770b3c588fc0de
Author: github-actions[bot]
<41898282+github-actions[bot]@users.noreply.github.com>
AuthorDate: Wed Dec 31 17:45:34 2025 +0100
[v3-1-test] [DISCUSSION-54853] Update webserver probe health check doc
(#59942) (#59982)
* [DISCUSSION-54853] Update webserver probe health check doc
* Remove empty line before health check note
* fix indentation on docs
(cherry picked from commit 1d6e79f960afcf4b47b0cc555f7abdecaefe8177)
Co-authored-by: Xu Han <[email protected]>
---
.../logging-monitoring/check-health.rst | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git
a/airflow-core/docs/administration-and-deployment/logging-monitoring/check-health.rst
b/airflow-core/docs/administration-and-deployment/logging-monitoring/check-health.rst
index c803791762e..c9b1966714a 100644
---
a/airflow-core/docs/administration-and-deployment/logging-monitoring/check-health.rst
+++
b/airflow-core/docs/administration-and-deployment/logging-monitoring/check-health.rst
@@ -36,7 +36,7 @@ Webserver Health Check Endpoint
-------------------------------
To check the health status of your Airflow instance, you can simply access the
endpoint
-``/api/v2/monitor/health``. It will return a JSON object in which a high-level
glance is provided.
+``/api/v2/monitor/health``. It will return a JSON object that provides a
high-level glance at the health status across multiple Airflow components.
.. code-block:: JSON
@@ -86,9 +86,12 @@ Served by the web server, this health check endpoint is
independent of the newer
.. note::
- For this check to work, at least one working web server is required. Suppose
you use this check for scheduler
- monitoring, then in case of failure of the web server, you will lose the
ability to monitor scheduler, which means
- that it can be restarted even if it is in good condition. For greater
confidence, consider using :ref:`CLI Check for Scheduler
<check-health/cli-checks-for-scheduler>` or :ref:`Scheduler Health Check
Server <check-health/scheduler-health-check-server>`.
+ * For this check to work, at least one working web server is required.
Suppose you use this check for scheduler
+ monitoring, then in case of failure of the web server, you will lose the
ability to monitor scheduler, which means
+ that it can be restarted even if it is in good condition. For greater
confidence, consider using :ref:`CLI Check for Scheduler
<check-health/cli-checks-for-scheduler>` or :ref:`Scheduler Health Check
Server <check-health/scheduler-health-check-server>`.
+
+ * Using this endpoint as webserver probes (liveness/readiness) makes it
contingent on Airflow core components' availability (database, scheduler, etc).
+ Webservers will be frequently restarted if any of these core components
are down. To make Webservers less prone to other components' failures, consider
using endpoints like ``api/v2/version``.
.. _check-health/scheduler-health-check-server:
