How do you allow power users to configure alerts via API without overprivileging them?

rsmsdk — Tue, 30 Jun 2026 12:39:13 GMT

Hi all,

We’re currently trying to figure out how other Dynatrace customers handle alert configuration via the API, especially when delegating this to power users in different development areas.

Up until now, we’ve mostly managed everything through the Dynatrace GUI. We’re not very mature yet in monitoring as code or in using the API extensively, but we can tell we’re reaching a point where we need to start doing things more systematically.

Our idea was:

- Give each development area its own API token
- Let those teams configure their own alerts via the API

However, from what I can see, alert configuration uses the Settings API, which in turn requires the settings:write scope. My understanding is that this scope allows write access to all settings configurations across the platform, not just alerting related ones.

That raises a few questions:

1. Is settings:write really all‑or‑nothing, or is there a way to scope it down to specific settings schemas or domains?

2. How are other customers handling this in practice?
- Do you actually give settings:write tokens to dev teams/power users?
- Do you restrict them in some other way?

3. Are there recommended patterns or best practices from Dynatrace for:
- Delegating alert configuration safely
- Avoiding “too much power” with a single token

Any examples of how you structure roles, tokens, or processes around this would be really helpful. We’re trying to balance flexibility for teams with not opening up the entire settings surface area.

In general, we just want users to be able to manage alerting to their liking in the best way possible; maybe we are overthinking it with the API solution.

Thanks in advance for any insights or patterns you can share!

Re: How do you allow power users to configure alerts via API without overprivileging them?

t_pawlak — Mon, 29 Jun 2026 12:40:10 GMT

Hi,

As far as I know, settings:write is not currently granular. It grants write access through the Settings API, and it cannot be scoped down to specific settings schemas (for example, only alerting-related settings). In practice, a token with settings:write can modify a much broader set of platform configuration than just alert definitions.

Because of that, I personally wouldn't hand out settings:write API tokens directly to development teams.

The patterns that seem to work best are:

Monitoring as Code – store alert definitions in Git (Terraform, Monaco, or your own deployment pipeline) and let a CI/CD pipeline deploy them using a centrally managed token with settings:write.
Broker/API layer – teams submit requests to an internal service or workflow, which validates things like Management Zones, naming conventions, or allowed alert types before calling the Dynatrace Settings API.
GUI + IAM roles – if the volume of changes is relatively low, using the UI with well-designed IAM roles and policies may actually be the simpler and safer option.

If your goal is to delegate ownership to individual teams, I'd also recommend combining this with:

Management Zones,
IAM policies to limit data visibility,
naming standards and change review processes.

Unfortunately, the Settings API itself doesn't currently provide a way to say, "this token may only manage alert settings for this specific team."

I'd be interested to hear how other customers approach this, but my impression is that larger organizations generally prefer a centralized GitOps/Monitoring-as-Code workflow over distributing settings:write tokens directly to power users.

Also, if you're looking at delegating permissions, I'd recommend spending some time on IAM policies rather than relying solely on API token scopes. We built a small Dynatrace Policy Calculator that helps generate least-privilege IAM policies for common use cases, which can be useful when designing roles for power users while keeping permissions as limited as possible:
Omnilogy Policy Manager / Policy Calculator

topic Re: How do you allow power users to configure alerts via API without overprivileging them? in Alerting

How do you allow power users to configure alerts via API without overprivileging them?

Re: How do you allow power users to configure alerts via API without overprivileging them?