<p>Check the login page, e.g. <a href="http://localhost:8080/login" rel="noreferrer">http://localhost:8080/login</a></p>

<p>Most pages are password protected but not this one (or you couldn't log in).</p>

CC BY-SA 4.0
2023-02-24T08:11:26.933Z
Excellent, didn't think of that.  My monitoring service was getting `403 Forbidden` errors when trying to hit the primary URL but this one worked fine.  (A browser was redirected the primary URL OK; not sure why that followed a different path.)
Alastair Irvine
CC BY-SA 4.0
2023-03-28T11:18:09.630Z
IMHO `http://localhost:8080/static/<anystring>/images/svgs/logo.svg` this URL will be less load to the server.
arulraj.net
CC BY-SA 4.0
2023-03-28T13:03:16.920Z
@arulraj.net feel free to add your own answer
Thorbjørn Ravn Andersen
CC BY-SA 4.0
2019-09-16T16:01:53.963Z
2019-09-16T16:01:53.963Z
Thorbjørn Ravn Andersen
<p>Check the logo of jenkins is accessible from outside.</p>
<p>For ex. <code>http://localhost:8080/static/&lt;anystring&gt;/images/svgs/logo.svg</code></p>
<p>This will less load to the server than login page.</p>

CC BY-SA 4.0
2023-10-05T20:47:35.200Z
The logo check as a health check, when starting a github service container in a github workflow succeeded before the jenkins service was ready to login when started from the docker image. Hence subsequent calls to the API failed with `Error communicating with server`. When I use the login check it works.
Max
CC BY-SA 4.0
2023-03-29T08:27:29.653Z
2023-03-29T08:27:29.653Z
arulraj.net
<p>For the sake of google completeness, since I just went and looked it up:</p>
<pre><code>/whoAmI/api/json?tree=authenticated
</code></pre>
<p>As in (taken from the helm):</p>
<pre><code>    readinessProbe:
        httpGet:
          path: {{ include &quot;oc.contextpath&quot; . }}/whoAmI/api/json?tree=authenticated
          port: {{ .Values.OperationsCenter.ContainerPort }}
        initialDelaySeconds: 30
        timeoutSeconds: 5
        failureThreshold: 100
    livenessProbe:
        httpGet:
          path: {{ include &quot;oc.contextpath&quot; . }}/whoAmI/api/json?tree=authenticated
          port: {{ .Values.OperationsCenter.ContainerPort }}
        initialDelaySeconds: 300
        timeoutSeconds: 5
        failureThreshold: {{ .Values.OperationsCenter.HealthProbeLivenessFailureThreshold }}
</code></pre>

CC BY-SA 4.0
2024-05-22T19:09:47.640Z
2024-05-22T19:09:47.640Z
Vetsin
<p><code>/api/json</code> will return 2.7 kB.  This is smaller than the login page, the <code>logo.svg</code>, and <code>favicon.svg</code>.  If Jenkins is responding but not ready for operation, then it returns HTML.</p>

CC BY-SA 4.0
2024-03-23T00:13:49.843Z
2024-03-23T00:13:49.843Z
Nathan
<p>The complication reside in the definition of the health status (and its usefulness).</p>

<p>You mentioned the definition being <code>service is up and web app application is operational</code> and for that indeed checking the homepage <em>should</em> suffice.</p>

<p>However that doesn't mean the service is properly configured for and correctly performing all the jobs that it's supposed to be doing. Without a consistent, universally acceptable definition of a health status there is no point of providing such information as a single, one-stop location to check.</p>

<p>But Jenkins offers via its <a href="https://wiki.jenkins.io/display/JENKINS/Remote+access+API" rel="noreferrer">Remote access API</a> various checking points that users can combine to derive their interpretation of the overall service health status. For example maybe checking the status of all the configured jobs or at least that of the critical ones would be more useful, which could be done using the <code>.../job_id/lastSuccessfulBuild/api/</code> or <code>.../job_id/api/</code> checkpoints. </p>

<p>The <a href="http://jenkinsapi.readthedocs.io/en/latest/" rel="noreferrer">JenkinsAPI</a> could also be of interest (better docs at least), found via <a href="https://stackoverflow.com/questions/25661362/where-can-i-find-jenkins-restful-api-reference">Where can I find jenkins restful api reference?</a></p>

CC BY-SA 3.0
2018-03-27T06:36:13.673Z
Interesting .. I didn't know about Jenkins API.
storm
CC BY-SA 4.0
2019-09-13T09:15:56.603Z
If "healthy" means "agents can connect to Jenkins", how can I check this as an anonymous user?
Thorbjørn Ravn Andersen
CC BY-SA 4.0
2019-09-13T10:50:02.500Z
@ThorbjørnRavnAndersen can you please ask this as a separate question? The comments section isn't a good fit for answers.
Dan Cornilescu
CC BY-SA 4.0
2019-09-13T11:04:41.167Z
My thoughts exactly, hence https://devops.stackexchange.com/questions/9159/anonymous-agents-can-connect-jenkins-health-check-url
Thorbjørn Ravn Andersen
CC BY-SA 3.0
2018-03-26T14:43:45.733Z
2018-03-26T14:43:45.733Z
Dan Cornilescu
<p>I'm planning to supervise services by periodically checking if they are up and running, Jenkins is our central orchestration tool and must be running with near zero downtime.</p>

<p>How can I check health status of a Jenkins server - <strong>By health status I mean service is up and web app application is operational</strong> ?</p>

<p>Does Jenkins provide a native health check URL ? Or does I need to make additional scripts?  if so what factors should be included in beside checking <code>jenkins.service</code> and curl web app home page.</p>

<jenkins>
Jenkins Health Check URL
storm
# Jenkins Health Check URL

(Asked by: username_0 on 2018-03-26)

I'm planning to supervise services by periodically checking if they are up and running, Jenkins is our central orchestration tool and must be running with near zero downtime.

How can I check health status of a Jenkins server - **By health status I mean service is up and web app application is operational** ?

Does Jenkins provide a native health check URL ? Or does I need to make additional scripts? if so what factors should be included in beside checking `jenkins.service` and curl web app home page.

**Tags:** jenkins


---

## 5 answers

### Answer by username_7 on 2018-03-26. Score: 9 | Accepted answer

The complication reside in the definition of the health status (and its usefulness).

You mentioned the definition being `service is up and web app application is operational` and for that indeed checking the homepage *should* suffice.

However that doesn't mean the service is properly configured for and correctly performing all the jobs that it's supposed to be doing. Without a consistent, universally acceptable definition of a health status there is no point of providing such information as a single, one-stop location to check.

But Jenkins offers via its [Remote access API](https://wiki.jenkins.io/display/JENKINS/Remote+access+API) various checking points that users can combine to derive their interpretation of the overall service health status. For example maybe checking the status of all the configured jobs or at least that of the critical ones would be more useful, which could be done using the `.../job_id/lastSuccessfulBuild/api/` or `.../job_id/api/` checkpoints.

The [JenkinsAPI](http://jenkinsapi.readthedocs.io/en/latest/) could also be of interest (better docs at least), found via [Where can I find jenkins restful api reference?](https://stackoverflow.com/questions/25661362/where-can-i-find-jenkins-restful-api-reference)

> **Comments:**
> **username_0**: Interesting .. I didn't know about Jenkins API.  
> **username_1**: If "healthy" means "agents can connect to Jenkins", how can I check this as an anonymous user?  
> **username_7**: @ThorbjørnRavnAndersen can you please ask this as a separate question? The comments section isn't a good fit for answers.  
> **username_1**: My thoughts exactly, hence https://devops.stackexchange.com/questions/9159/anonymous-agents-can-connect-jenkins-health-check-url  

---

### Answer by username_1 on 2019-09-16. Score: 16

Check the login page, e.g. <http://localhost:8080/login>

Most pages are password protected but not this one (or you couldn't log in).

> **Comments:**
> **username_2**: Excellent, didn't think of that.  My monitoring service was getting `403 Forbidden` errors when trying to hit the primary URL but this one worked fine.  (A browser was redirected the primary URL OK; not sure why that followed a different path.)  
> **username_3**: IMHO `http://localhost:8080/static/<anystring>/images/svgs/logo.svg` this URL will be less load to the server.  
> **username_1**: @username_3 feel free to add your own answer  

---

### Answer by username_3 on 2023-03-29. Score: 1

Check the logo of jenkins is accessible from outside.

For ex. `http://localhost:8080/static//images/svgs/logo.svg`

This will less load to the server than login page.

> **Comments:**
> **username_4**: The logo check as a health check, when starting a github service container in a github workflow succeeded before the jenkins service was ready to login when started from the docker image. Hence subsequent calls to the API failed with `Error communicating with server`. When I use the login check it works.  

---

### Answer by username_5 on 2024-05-22. Score: 0

For the sake of google completeness, since I just went and looked it up:
/whoAmI/api/json?tree=authenticated

As in (taken from the helm):
    readinessProbe:
        httpGet:
          path: {{ include "oc.contextpath" . }}/whoAmI/api/json?tree=authenticated
          port: {{ .Values.OperationsCenter.ContainerPort }}
        initialDelaySeconds: 30
        timeoutSeconds: 5
        failureThreshold: 100
    livenessProbe:
        httpGet:
          path: {{ include "oc.contextpath" . }}/whoAmI/api/json?tree=authenticated
          port: {{ .Values.OperationsCenter.ContainerPort }}
        initialDelaySeconds: 300
        timeoutSeconds: 5
        failureThreshold: {{ .Values.OperationsCenter.HealthProbeLivenessFailureThreshold }}


---

### Answer by username_6 on 2024-03-23. Score: 0

`/api/json` will return 2.7 kB. This is smaller than the login page, the `logo.svg`, and `favicon.svg`. If Jenkins is responding but not ready for operation, then it returns HTML.


---

