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)	< 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 and latency: dtm_dns_queries_total and dtm_dns_query_duration_seconds.
• API success: dtm_api_requests_total.
• Replication lag: dtm_replication_last_sync_timestamp_seconds.
• Cluster availability: dtm_cluster_nodes.
• Liveness: dtm_heartbeat.

For alerting, 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.

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].