> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Demo Clarification
> Describes how an AnalysisRun succeeded because the AnalysisTemplate checks result.code in the JSON health response instead of the HTTP status.
This lesson explains why the AnalysisRun succeeded even though earlier sessions showed a different health payload. The key point: the AnalysisTemplate evaluates a JSON field inside the health endpoint response (result.code), not the HTTP status code.
The AnalysisRun invoked the health check three times and evaluated the success condition against the JSON payload returned by the service. The metric reads show three values (one per probe):
```text theme={null}
Value Time
[object Object] 12:48:52 AM
[object Object] 12:48:57 AM
[object Object] 12:49:02 AM
Success condition: result.code >= 200 && result.code < 300
```
Because the AnalysisTemplate inspects `result.code`, the content of the JSON body matters. Below are two versions of the health response and the relevant AnalysisTemplate snippet.
Frame the successful (green) version JSON — it includes a numeric `code` field:
```json theme={null}
{
"code": 200,
"status": "OK",
"message": "Highway Animation Server is running",
"timestamp": 1761386576672
}
```
Note: The AnalysisTemplate's success condition checks the JSON payload (for example, `result.code`). It does not evaluate the HTTP response code returned by the server.
Here is the AnalysisTemplate as shown by kubectl (trimmed to the relevant fields). Notice the web provider URL and the same success condition:
```bash theme={null}
$ k -n argo-analysis-lab describe at http-health-check
Name: http-health-check
Namespace: argo-analysis-lab
Kind: AnalysisTemplate
Spec:
Args:
Name: service-name
Metrics:
Count: 3
Interval: 5s
Name: health-check
Provider:
Web:
Method: GET
URL: http://{{args.service-name}}.argo-analysis-lab.svc.cluster.local/health
Success Condition: result.code >= 200 && result.code < 300
```
Contrast that with the older (blue) version of the application whose health endpoint returned a simpler payload without a `code` field:
```json theme={null}
{
"status": "OK",
"message": "Highway Animation Server is running"
}
```
If the AnalysisRun queries a response that lacks `result.code`, the metric extraction for `result.code` will fail and the success condition cannot be satisfied — even if the HTTP status is 200. Ensure the JSON payload contains the field referenced by your success condition.
Summary — why the AnalysisRun passed
* The AnalysisTemplate success condition is evaluated against the JSON payload returned by the health endpoint (e.g., `result.code`).
* The green version includes the `code` field with a value in the 200–299 range, satisfying the condition.
* The blue version lacks the `code` field, so the same AnalysisTemplate would fail when run against it.
Comparison table
| Aspect | Green version (passed) | Blue version (would fail) |
| ------------------------------------------------------------- | ---------------------- | ------------------------- |
| JSON payload includes `code` | Yes (`"code": 200`) | No |
| Success condition (`result.code >= 200 && result.code < 300`) | Evaluates to true | Fails (field missing) |
| AnalysisRun result | Success | Failure |
Links and references
* [Argo Rollouts — AnalysisOverview](https://argoproj.github.io/argo-rollouts/features/analysis/)
* [Argo Workflows Documentation](https://argoproj.github.io/argo-workflows/)
* Consider using JSONPath or JQ locally to inspect responses: e.g., `curl -s http://svc/health | jq .`