SLA and SLO

This page describes the availability and performance targets DTM is engineered to, and how you can verify them from your own monitoring. Every Marketplace deployment includes support on a best-effort basis; these SLO targets are an engineering commitment you can measure, not a contractual SLA. A formal, SLA-backed support tier (with availability commitments and service credits) is available separately under a written agreement.

Service-level objectives

Each objective is anchored to a metric you can scrape yourself (see observability), so you can hold the service to it independently.

Objective	Target	Window
Authoritative DNS success (answers not SERVFAIL / REFUSED)	99.95%	30-day rolling
DNS query latency (p99, authoritative answers)	< 10 ms	30-day rolling
REST API success (non-5xx)	99.9%	30-day rolling
Replication convergence lag	< 60 s	30-day rolling
Cluster availability (at least 2 alive members, multi-node)	99.9%	30-day rolling
Heartbeat liveness	every node at least every 60 s	continuous

A 99.95% monthly DNS target is roughly 21 minutes of error budget per month; the 99.9% API target is roughly 43 minutes.

Verifying against your own metrics

The objectives map directly to exported dtm_* metrics:

• DNS success: dtm_dns_queries_total.
• DNS latency: dtm_dns_query_duration_seconds filtered to authoritative="true", the answers DTM gives itself from a zone it owns or a static override (forwarded queries carry authoritative="false"). For example, the p99 over five minutes is histogram_quantile(0.99, sum by (le) (rate(dtm_dns_query_duration_seconds_bucket{authoritative="true"}[5m]))). The histogram records DTM’s server-side processing time, timed inside its DNS handler, not the round trip a client sees: a measurement taken at the client or on the wire adds network and socket time, so it reads higher than this objective.
• API success: dtm_api_requests_total.
• Replication lag: dtm_replication_last_sync_timestamp_seconds.
• Cluster availability: dtm_cluster_nodes.
• Liveness: dtm_heartbeat.

For alerting, start from the shipped rules on the Alerting page: on Prometheus, DTMDNSLatencyAboveSLO warns when authoritative p99 latency stays above 10 ms for 15 minutes, and the critical DTMDNSLatencyHigh pages when p95 exceeds 50 ms. For error-budget teams, a multi-window burn-rate approach works well: page on a fast burn of the error budget and open a ticket on a slower burn. Replication lag and DNS latency are simple above-threshold alerts.

Availability scope

The service targets cover the DTM software: DNS availability, API availability, and replication behaviour. They do not cover the underlying Azure infrastructure (VMs, networking, storage), which is governed by Microsoft’s own SLAs, nor customer-side misconfiguration (for example NSG or VNet peering issues). DTM is designed to survive single-node failure without DNS downtime when run as a multi-node cluster. The latency objective covers answers DTM serves from its own zones: a forwarded query waits on the upstream resolver, so its latency depends on that resolver and is not covered by the latency objective.

Maintenance

Planned software maintenance is performed via rolling upgrade, which is zero-downtime for DNS on a multi-node cluster. Non-emergency maintenance windows are announced in advance.

Support and the formal SLA

Every Marketplace deployment includes support on a best-effort basis. A formal SLA, adding availability commitments, support-response targets by severity, and service credits, is a separate tier under a written agreement. To discuss it, contact [email protected].