dt-sdlc-quality-gates

Create a Lifecycle Guardian in the Site Reliability Guardian app with DQL objectives for error rate, latency, and availability. Then build a Dynatrace Workflow triggered by a deployment event that runs the guardian validation and returns a PASS or FAIL verdict to your pipeline.

The pipeline does not call the guardian directly; it triggers a Dynatrace Workflow. Use SDLC events with the openpipeline.events_sdlc token scope, custom deployment events, or the Workflow Execution API, then poll for the validation result.

Start with error rate, p90 response time, availability, and new DAVIS problem count. Each DQL objective must return exactly one numeric value, so use summarize or fieldsAdd to aggregate to a single row before applying thresholds.

Static thresholds use fixed target and warning values you define, suited for known acceptable ranges. Auto-adaptive thresholds let DAVIS analyze 30 days of history to set values, which works well when you do not know your service's normal baseline.

ERROR usually means the DQL query is invalid, so test it independently first. Null values indicate no data in the timeframe, typically caused by a wrong service entity ID, missing instrumentation, or a time window that is too short.

Yes. Define guardian variables such as service_id and reference them in DQL with $variable_name syntax. Override the variables when triggering the workflow so the same guardian validates different services or environments with environment-specific thresholds.