Skip to main content
This lesson shows how to create an Argo Rollouts AnalysisTemplate — the reusable resource that defines how to perform runtime analysis during progressive delivery. AnalysisTemplates specify which metrics to collect, how often to collect them, how many samples to take, and what constitutes success or failure. They can accept runtime arguments (including secrets) so Rollouts can pass contextual values into the template. Below is a minimal AnalysisTemplate manifest showing the resource kind and metadata:
AnalysisTemplates can be namespaced (as shown above) or cluster-scoped. Cluster-level templates use the same API but are available to Rollouts across the cluster.

Template arguments (args)

AnalysisTemplates accept args (input parameters) that Rollouts supply at runtime. An arg can be required (no default) or optional (with a default value). Args can also be populated from Kubernetes Secrets using valueFrom.secretKeyRef. Example of args and metrics declared in an AnalysisTemplate:
To reference an argument inside the template use the args namespace, for example {{ args.service-name }}.
Arguments are substituted at runtime using the template expression {{ args.<name> }}. Ensure the argument names in your Rollout match exactly those declared in the AnalysisTemplate.

Metrics, providers, and conditions

The core of an AnalysisTemplate is the metrics list. Each metric declares:
  • A name
  • A sampling cadence (interval)
  • How many samples (count) or an allowed number of failures (failureLimit)
  • A successCondition and optional failureCondition to evaluate the provider result
  • A provider (Prometheus, Datadog, New Relic, Job, Web/HTTP, CloudWatch, etc.)
The provider block defines how the metric is measured (query, HTTP call, job execution, etc.). The successCondition and failureCondition receive a result object whose structure depends on the provider (for web, result.code is HTTP status; for Prometheus, result is typically a vector/array). Common providers at a glance:

Prometheus provider example

Prometheus query results are returned in vector form, so you typically index into result (for example result[0]) when writing successCondition.
Hints:
  • Use failureLimit to allow a small number of failing samples before the analysis fails.
  • Choose interval to balance responsiveness with query load.

Web (HTTP) provider example

The web provider performs HTTP requests to gather a measurement. You can configure the URL, HTTP method, headers, timeout, and optional JSON path to extract values from the response body.
Notes:
  • Use jsonPath to extract a specific value from JSON responses; the extracted value becomes result.
  • timeoutSeconds defaults to 10s unless overridden.

Example: HTTP health-check AnalysisTemplate

This complete AnalysisTemplate uses the web provider to call a service /health endpoint. It runs 3 probes at 5-second intervals and treats any 2xx HTTP status as success.
Key details:
  • count: 3 — the probe will be executed three times.
  • interval: 5s — delay between successive probes.
  • successCondition — for the web provider, result.code contains the HTTP response status code.
Use count and interval to control sample size and cadence. Collecting multiple samples helps smooth out transient failures and reduces flakiness in progressive rollouts.

Create the AnalysisTemplate

Apply the manifest to create the AnalysisTemplate in the target namespace:
Expected response:
Verify the template exists:
Example output:
Describe the template to inspect args and metrics:
Relevant fields in the describe output (formatted for clarity):
Now the AnalysisTemplate exists and is ready to be referenced by a Rollout in this namespace. Wire the template into a Rollout’s analysis section to execute these checks as part of a progressive delivery strategy. For additional examples and provider details, consult the Argo Rollouts AnalysisTemplates guide in the official documentation.

Watch Video