Validate a Site Reliability guardian

Latest Dynatrace
Tutorial
8-min read
Published Oct 24, 2025

Validating a Site Reliability guardian allows teams to automatically or manually evaluate service reliability, business objectives, and lifecycle quality gates.

Target audience

Site Reliability Engineers (SREs)
DevOps engineers
Platform engineers
Development teams

Learning outcome

In this tutorial, you'll learn how to trigger a Site Reliability guardian validation using Site Reliability Guardian, Workflows Workflows, event-based triggers, and APIs enabling continuous reliability validation, CI/CD integration, and automated release validation.

Before you begin

Knowledge of how to Create a Site Reliability guardian.

How-to

You can trigger a guardian validation in the following ways:

Manually, using the Site Reliability Guardian.
Automatically, by setting up a workflow with a Site Reliability Guardian action.

Validate a guardian manually using Site Reliability Guardian

To manually validate a guardian, either select the Validate button on either of

All guardians page.
The upper right corner of a guardian's detail page.

You can provide guardian variables and a timeframe in the pop-up window. For more information, see Add Site Reliability Guardian objective.

Select the Validate button to start a validation.

Validate a guardian automatically

To automatically trigger a guardian validation, you need to set up a workflow, choose the right trigger, and add a Site Reliability Guardian Site Reliability Guardian action. This action validates your guardian.

1. Set up an event trigger

Go to Workflows.
In the Select a trigger pane on the right, scroll down and select event trigger.

You can trigger the validation and run the workflow from the AutomationEngine API or by using an On demand trigger in your workflow. You can also run the validation and workflow using one of the Event triggers to utilize the various event types.

Depending on the kind of guardian you choose, you can use an event trigger and the following two types of events.

business events: select the event type of bizevents for a business guardian.
SDLC events: select the event type of events and add a filter for event.kind == "SDLC_EVENT" for a lifecycle guardian.

Good practice
Trigger a business guardian validation with a business event or a lifecycle guardian with SDLC events.

Examples of a Filter query

Provide a Filter query only to trigger a validation if an incoming event satisfies this query. The Filter query is based on Dynatrace Query Language.

Having a filter that is not restrictive enough may lead to the workflow being over-triggered. Using a filter that is too restrictive, on the other hand, would lead to not triggering at all.

Defining a set of event fields can serve multiple purposes.

You can use it in the event filter query to determine whether the workflow should be run or not.
It can provide information for the Site Reliability Guardian action to parameterize the guardian validation.
It can add extra context to your workflow execution if there are further actions defined, for example, notifications.

To define the event payload

Define the minimum set of event data.

Let's start with the minimum set of event data just to trigger a workflow. You need to have at least one field, and you can align the payload with the event definitions from the Semantic Dictionary. This is not mandatory, but it would make querying related events easier.

The following examples assume the event type with SDLC event ingestion for a lifecycle guardian. You can achieve the same result by selecting the bizevents type with business events ingest for a business guardian. The only difference would be to remove the line event.kind == "SDLC_EVENT" and in the filter queries.

This is a minimal event payload JSON example.
```
{
  "event.type": "validation.triggered"
}
```
This is the resulting DQL event filter query.
```
event.kind == "SDLC_EVENT" and
event.type == "validation.triggered"
```
Add fields to the event payload.

Having the same event filter query for every workflow related to guardian validation is potentially unintended, so adding additional fields to the event payload and the filter query to only trigger a selected workflow is necessary.

Add a unique identifier to make the filter query a lot more restrictive and tie the validation of a specific guardian to it. You can pick whatever you want as an identifier, for example, a unique service name or a combination of service and environment, or any other identifier that is unique for this purpose.

This is a minimal event payload with a unique identifier, as shown in the following JSON example.
```
{
  "event.type": "validation.triggered",
  "unique_id": "my-unique-id-1234"
}
```
This is the resulting DQL event query with the added filter for unique_id
```
event.kind == "SDLC_EVENT" and
event.type == "validation.triggered" and
unique_id == "my-unique-id-1234"
```
If you also want to make the validation timeframe configurable for the guardian validation, then you can add two more fields to the event payload. Let's add timeframe.to and timeframe.from, both in ISO 8601 format ('yyyy-MM-dd'T'HH:mm:ss.SSS'Z') so you can use them later on.
```
{
  "event.type": "validation.triggered",
  "unique_id": "my-unique-id-1234",
  "timeframe.from": "2025-10-23T14:05:00Z",
  "timeframe.to": "2025-10-23T14:20:00Z"
}
```
The event filter query for the event trigger remains unchanged from the above.

2. Add the Site Reliability Guardian action in Workflows

Add the Site Reliability Guardian Site Reliability Guardian action.

Select the on the trigger node to browse all available actions.
Search for Site Reliability Guardian, or srg as a shorthand, in the search field of the Choose action panel and select it.
In the Input tab of the Site Reliability Guardian action, select the Guardian.
Provide an expression that references the event input data.
In the Timeframe section, select the Enter an expression to select timeframe from a previous task or event trigger and use an expression to extract the Timeframe from the triggering event. Use {{event()['timeframe.from']}} for the From input field and {{event()['timeframe.to']}} for the To input field.

Guardian variables
You could provide dynamic event data to configure guardian variables in the Variables section of the guardian. You need to set up these variables in your guardian configuration before you can reference them in the guardian workflow action. Also, the variable names need to match exactly for this to work.
Select Save draft.
Select Deploy.
Select Run.

For more information, see Create workflows in Dynatrace Workflows.

3. Trigger the validation

After you created a workflow with an event trigger and an Site Reliability Guardian Site Reliability Guardian action, you need to trigger it.

You have a couple of options:

Event
Automation service API

Event

Trigger the workflow with an event and validate the guardian. To ingest an SDLC event, you need to use the OpenPipeline ingest API for SDLC events, and you need to have an Access token with the openpipeline.events_sdlc scope.

The OpenPipeline SDLC event ingest API doesn't return any response payload, but only HTTP status 202 in case of success.

You can use curl to send an HTTP POST request with the payload from above. Make sure to replace <YOUR-ENVIRONMENT-ID> with your Dynatrace environment ID and <YOUR-ACCESS-TOKEN> with your Dynatrace access token.

This is an example of the curl to send an HTTP POST request with the payload from the previous step.

curl -i -X 'POST' \
'https://<your-environment-id>.live.dynatrace.com/platform/ingest/v1/events.sdlc' \
-H 'accept: */*' \
-H 'Authorization: Api-Token <YOUR-ACCESS-TOKEN>' \
-H 'Content-Type: application/json; charset=utf-8' \
-d '{
  "event.type": "validation.triggered",
  "unique_id": "my-unique-id-1234",
  "timeframe.from": "2025-10-23T14:05:00Z",
  "timeframe.to": "2025-10-23T14:20:00Z"
}'

Automation service API

You can run a workflow directly from the API.

To run the workflow, you need

To identify the workflow by ID called UUID, you need to find it in the address bar of your browser, for example, 807b49a7-38d2-4d45-a39b-807aefa15b93 in .../ui/apps/dynatrace.automations/workflows/807b49a7-38d2-4d45-a39b-807aefa15b93 when the workflow is open.
A Platform token with at least the automation:workflows:run scope for authorization.

The Automation service API expects a JSON payload that should be nested under the input field.

If you only want to use API triggers for your workflow, you can adjust all expressions to use the input() expression instead of the event() expression.

If you would like to use event triggers and API triggers in a workflow with expressions, you need to extend all expressions to include both options, for example,

{% if event() %}{{event()['timeframe.from']}}{% else %}{{input()['timeframe.from']}}{% endif %}

Since you trigger the workflow using the API, you don't need to incorporate the parts of the data that belong to the filter query, as this only triggers the workflow identified by the ID we provide. You can omit the fields "unique_id": "my-unique-id-1234" and "event.type": "validation.triggered" in the payload.

You can use curl to send an HTTP POST request with the payload. Make sure to replace YOUR-WORKFLOW-ID with the workflow ID you have identified, <YOUR-ENVIRONMENT-ID> with your Dynatrace environment ID, and <YOUR-PLATFORM-TOKEN> with your Dynatrace platform token.

This is an example of sending an HTTP POST request with a payload.

curl -X 'POST' \
'https://<YOUR-ENVIRONMENT-ID>.apps.dynatrace.com/platform/automation/v1/workflows/<YOUR-WORKFLOW-ID>/run' \
-H 'accept: */*' \
-H 'Authorization: Bearer <YOUR-PLATFORM-TOKEN>' \
-H 'Content-Type: application/json; charset=utf-8' \
-d '{
  "input": {
    "timeframe.from": "2025-10-23T14:05:00Z",
    "timeframe.to": "2025-10-23T14:20:00Z"
  }
}'