End to End Monitoring and alerting as code with dtctl and GitHub Co-Pilot

[Georgi_V]

I just learned that Dynatrace dtctl cli also supports OS Service monitoring policies as YAML.
This is great for automation, let's say you want to monitor specific OS services and trigger alerting workflows on specific conditions, the entire solution can be codified and pushed out via GitHub co-pilot. True zero touch provisioning.
dtctl creates the OS service monitoring policies and pairs them with Davis triggered workflows also defined as code and ready to be committed to your repo.

[anuj-jain08]

The scenario you've described mixes real Dynatrace capabilities with some claims that aren't accurate:
What dtctl actually supports:

• Workflows, dashboards, notebooks, DQL queries, SLOs, Azure connections, settings, and extensions — managed as code via CLI
• CI/CD pipeline automation and version control of platform resources
• AI agent-driven automation (it's explicitly designed for this)

What's not accurate:

• dtctl does not have a documented feature for OS Service monitoring policies as YAML. This is not a known capability of dtctl. OS service monitoring in Dynatrace is configured via OneAgent settings (through the Settings API / dt.settings schema), not as a dedicated dtctl resource type.
• "GitHub Copilot pushing dtctl configs" — GitHub Copilot is a code completion tool; it doesn't natively push or execute dtctl commands. You could write automation scripts that use dtctl and commit them to a repo, but that's standard scripting, not a Dynatrace-specific integration.

What the real "as-code" story looks like for OS service monitoring
If you want to codify OS service monitoring and alerting, here's what actually works today:
OS service monitoring configuration:

• Managed via the Dynatrace Settings API using the builtin:host.service-monitoring settings schema
• Can be exported and applied as JSON/YAML via tools like Terraform (dynatrace provider), the Settings API directly, or Monaco (Monitoring as Code)

Alerting workflows:

• Workflows can be managed as code via dtctl — this part is real and well-supported
• Davis-triggered workflows can be defined, versioned, and deployed via dtctl workflow commands

True GitOps flow (what's actually possible):

1. Define OS service monitoring settings as JSON via Monaco or Terraform
2. Define alerting workflows via dtctl or Terraform
3. Commit both to a repo and deploy via CI/CD

Suggestion:
If zero-touch provisioning for OS service monitoring + alerting is your goal, Monaco (Monitoring as Code) combined with dtctl for workflows is the most complete path today. The Monaco documentation covers this in detail.