Try it free

Set up automated release validation with Site Reliability Guardian

  • Latest Dynatrace
  • Tutorial
  • 7-min read

Every deployment is a risk. The faster you know whether a release meets your reliability objectives, the faster you can act, and promote with confidence or roll back before users are affected. This tutorial shows you how to automate that decision using Workflows Workflows, Site Reliability Guardian Site Reliability Guardian, and SDLC events, or Business events.

Dynatrace recommends using SDLC events to implement the release validation use case. Business events are also supported.

Who is this for?

This tutorial is for DevOps engineers, platform engineers, and site reliability engineers who want to automate release validation within a CI/CD pipeline. It assumes you manage deployment pipelines and have access to a Dynatrace environment with Workflows Workflows and Site Reliability Guardian Site Reliability Guardian turned on.

What will you learn?

In this tutorial, you'll learn how to:

  • Send a deployment finished SDLC event from your CI/CD pipeline to Dynatrace.
  • Create a lifecycle guardian that defines pass/fail objectives for your service.
  • Configure a workflow to trigger a guardian validation when a deployment event arrives.
  • Query validation results in DQL and use them to promote or block a release.

Before you begin

Prerequisites

  • A Dynatrace environment with Workflows Workflows and Site Reliability Guardian Site Reliability Guardian turned on.

  • An access token with the openpipeline.events_sdlc scope.

  • The following Workflows permissions required if your pipeline triggers validations through the API or automates workflow execution.

    • automation:workflows:read: View workflows

    • automation:workflows:admin: Create and edit workflows

    • automation:workflows:run: Trigger a workflow via API

Prior knowledge

  • Familiarity with SDLC events and how they flow through OpenPipeline.
  • Basic understanding of Site Reliability Guardian Site Reliability Guardian objectives and Site Reliability Guardian Site Reliability Guardian indicators.

Set up automated release validation

Automated release validation connects your CI/CD pipeline to Site Reliability Guardian Site Reliability Guardian through SDLC events.

When a deployment finishes, Dynatrace:

  1. Receives an event.
  2. Triggers a guardian validation.
  3. Stores the result as a new SDLC event that you can query and act on.

1. Send deployment events from your CI/CD pipeline

To send events, use one of the following methods:

  • Required CI/CD integrations: Dynatrace provides native integrations for GitHub Actions, GitLab, Azure DevOps, Argo CD, and other CI/CD tools. These integrations handle authentication and event formatting automatically. For more information, see pipeline observability.
  • API: Send a POST request directly to the SDLC events ingestion endpoint. For more information, see Ingest SDLC events for the endpoint URL, authentication details, and payload format.

For the full event schema, see SDLC events semantic dictionary.

Your CI/CD pipeline must send a deployment finished SDLC event to Dynatrace when a deployment completes. Dynatrace uses the event's timeframe to scope the Guardian validation.

Include the following key fields in the event payload:

FieldExample valueDescription

event.type

deployment

Identifies the event as a deployment

event.status

finished

Marks the deployment as completed

cicd.deployment.id

deploy-2026-001

Unique identifier for this deployment run

cicd.deployment.name

payment-service

Name of the deployed service

cicd.deployment.release_stage

staging

Deployment environment (development, staging, production)

cicd.deployment.status

succeeded

Outcome of the deployment

Result: When your pipeline finishes a deployment, Dynatrace receives a deployment finished event and makes it available for the workflow trigger.

2. Create a lifecycle guardian

A lifecycle guardian defines the objectives your service must meet to pass validation. To get started quickly, use a predefined template such as Four golden signals, which covers latency, traffic, errors, and saturation.

  1. Create a guardian from the Four golden signals template.

  2. Add at least one tag, for example, service:payment-api or stage:staging, so you can filter validation results by tag in DQL queries (Step 4). Alternatively, use the guardian ID, which you can copy from the browser address bar when viewing the guardian.

  3. Define the variables that the workflow passes in Configure a workflow to trigger validation step. Variable names must match exactly what the workflow provides in the next step.

    VariableDescription

    deployment.name

    Name of the deployment

    service.id

    Identifier of the deployed service

    commit_revision

    Git commit revision of the deployed code

    version

    Version of the deployed artifact

Result: Your guardian is saved and tagged. Copy the guardian ID from the browser address bar; you'll need it when you configure the workflow.

For more information, see Create a Site Reliability guardian for available templates and objective configuration options.

3. Configure a workflow to trigger validation

A workflow listens for the deployment finished SDLC event and automatically triggers your lifecycle guardian.

To configure a workflow:

  1. Go to Workflows Workflows.

  2. Create a blank workflow.

  3. Configure the trigger.

    1. Set the trigger type to Event.

    2. Copy and paste the following filter query in the event trigger's Filter query field to match deployment events for your service.

      event.kind == "SDLC_EVENT" AND event.type == "deployment" AND event.status == "finished"

      Optionally, you can filter by stage by adding AND cicd.deployment.release_stage == "staging" to your query.

  4. Add a Site Reliability Guardian action.

  5. Select the Guardian you created in the Create a lifecycle guardian step.

  6. Set the Timeframe to Last 2 hours. Adjust the timeframe to match your typical deployment and stabilization window. A shorter time window reduces noise, while a longer one captures slower-emerging issues.

  7. Define the guardian variables in your guardian configuration if you haven't done it yet. Names must match exactly.

  8. Pass the guardian variables from the incoming event to store the release metadata in the Guardian result.

  9. Map them in the workflow action:

    Guardian variableExpressionSource field

    deployment.name

    {{event()['cicd.deployment.name']}}

    Name of the deployment

    service.id

    {{event()['cicd.deployment.service.id']}}

    Identifier of the deployed service

    commit_revision

    {{event()['vcs.ref.base.revision']}}

    Git commit revision of the deployed code

    version

    {{event()['event.version']}}

    Version of the deployed artifact

  10. Select Create draft.

  11. Select Deploy.

  12. Select Run.

  13. Trigger the validation.

Result: When a deployment finished event occurs, the workflow automatically triggers guardian validation.

4. Query validation results and act on them

After the guardian completes a validation, Dynatrace emits a validation finished SDLC event.

Use the following DQL query to retrieve results and drive pipeline decisions:

fetch events
| filter event.kind == "SDLC_EVENT"
| filter event.provider == "dynatrace.site.reliability.guardian"
| filter event.type == "validation"
| filter event.status == "finished"
| filter contains(dt.srg.tags, "payment-api")
| fields timestamp,
validation.result,
version = event.version,
guardian_name = dt.srg.name,
guardian_id = dt.srg.id,
guardian_objective_results = dt.srg.validation.summary,
executed_workflow = dt.automation_engine.workflow.id

To inspect individual objective results, filter for event.type == "validation.objective" instead.

Result: Based on the DQL query you retrieved results which you can use drive pipeline decisions.

For more information, see SRG event structure.

5. Add follow-up actions to workflow

Extend the workflow with conditional actions based on the validation result. For more information, see workflow actions for the full list of available actions.

  • Pass: This triggers a downstream pipeline step or deployment promotion.
  • Fail: This blocks the pipeline or creates a ticket.
  • Notify: This sends a Slack or Microsoft Teams message with the validation result.

Result: You extended the workflow with conditional workflow actions such as notifications.

Congratulations!

You've set up automated release validation with Site Reliability Guardian Site Reliability Guardian.

Your pipeline can now:

  • Send deployment events to Dynatrace when a release finishes.
  • Trigger a lifecycle guardian validation automatically via a workflow.
  • Query validation results in DQL and act on them to promote or block a release.

As next steps, consider:

  • Adding more objectives to your guardian to cover additional reliability signals.
  • Configuring targeted notifications to alert your team when a validation fails.
Related tags
Application ObservabilitySite Reliability GuardianSite Reliability GuardianWorkflowsWorkflows