← Back to home

Last updated 1 October 2026

Service Level Agreement

This Service Level Agreement (SLA) applies to an Enterprise customer when the customer's accepted order or agreement incorporates it.

It covers availability of the production authoritative DNS nameserver infrastructure serving DNS by echo reply. It does not cover Basis or free service, domain registration or registry services, add-ons, RADIUS, or features marked beta, preview, or experimental.

This SLA is incorporated into and subject to our Terms of Service. If the documents conflict, an individually signed agreement or accepted order takes precedence for the subject it addresses. This SLA then takes precedence over the Terms of Service only for the availability commitment and service credits described here. The Acceptable Use Policy continues to govern acceptable use and enforcement, and the Privacy Policy describes personal-data processing.

1. Uptime commitment

For a covered Enterprise service, echo reply commits to 99.99% monthly uptime for its authoritative DNS nameserver infrastructure. The monitored nameservers are ns1.echo-reply.net, ns2.echo-reply.net, ns3.echo-reply.net, ns4.echo-reply.net and ns5.echo-reply.net. All five nameservers must serve the hosted zones in the covered service.

Independent test zone. We measure the ability of the nameservers to return the expected DNS response for an echo reply-controlled test zone. The test does not depend on customer records or a customer-operated Private Master. Receipt of an arbitrary DNS packet is not enough: an unexpected error response for the test query is a failed check. This is an infrastructure-availability commitment, not a guarantee that every customer-supplied record is correct.

The availability calculation does not measure the management interface, API, zone-update propagation or the correctness of each customer's zone. A successful test does not excuse a failure by us to deliver another part of the agreed service. Provider-caused errors affecting a customer's zone remain subject to our obligations and applicable remedies under the Terms of Service and law, even if they do not qualify for an availability credit under this SLA.

Probe locations. We check the nameservers every 30 seconds using monitoring probes operating in at least two different countries, on separate networks. We may change their locations while maintaining that separation. Each test has a five-second response timeout. Fixed countries or individual probe hosts are not part of this commitment.

Qualifying downtime. Subject to the exclusions below, downtime qualifies when all five nameservers fail the test from both designated monitoring locations in consecutive observations spanning at least 60 seconds. Partial nameserver failure, or failure observed from only one location, triggers investigation but does not by itself establish a complete outage under this SLA.

Once the 60-second threshold is confirmed, we count the full interval from the first failed observation establishing the simultaneous failure, including the first minute. The interval ends at the first confirmed successful test response from any monitored nameserver. Failures must be consecutive: missing observations do not establish continued failure or recovery. At a 30-second cadence, three failed observations are needed to span 60 seconds.

Monthly calculation. We use UTC calendar months and calculate uptime from total elapsed time and qualifying downtime, without rounding the uptime percentage before selecting a credit band:

Uptime % = ((Total time − Qualifying downtime) / Total time) × 100

Overlapping incidents are counted once. An incident crossing a month boundary contributes only its overlapping duration to each month after the continuous incident has been assessed against the 60-second threshold. Monitoring gaps or failures of the monitoring system are treated as unknown, not automatically as service availability. We review service logs and credible customer evidence where measurements are missing or disputed. If a material interval remains unknown after seeking independent corroborating evidence, we count that unresolved interval as downtime for the monthly service-credit calculation. The underlying monitoring record remains classified as unknown; this credit treatment does not establish a confirmed outage or a statutory incident classification. A customer report alone does not establish the outage duration, and you may ask us to review a claim decision.

A 30-day month contains 43,200 minutes. A 99.99% commitment permits 4.32 minutes (4 minutes and 19.2 seconds) of qualifying downtime before a credit is due. Interruptions that do not reach the 60-second qualifying threshold are not included in that total.

2. Maintenance and exclusions

We plan maintenance to keep at least one nameserver available. Planned work expected to affect service will be announced at least 48 hours in advance where practicable, through email, an in-service notice or our status page. Emergency work may begin immediately, with notification as soon as reasonably practicable. Maintenance is not automatically excluded from downtime: if it causes a complete outage meeting the measurement criteria above, that interval counts unless a separate exclusion below applies.

Failures of our servers, software, deployments or configuration count where the outage criteria are met. Hosting, power and connectivity supplied as part of our infrastructure are not automatically excluded merely because a supplier caused the failure.

The following are not counted as downtime for the purposes of this SLA:

  • Force majeure. Exceptional events beyond our reasonable control whose relevant effects could not reasonably have been prevented or mitigated. The exclusion applies only to the extent the event caused the outage despite reasonable prevention and mitigation. A supplier failure or denial-of-service attack is not automatically force majeure
  • Customer-caused issues. Failures caused by your DNS records, delegation, customer-controlled DNSSEC configuration, credentials, systems or instructions, including an unavailable or misconfigured customer-operated Private Master or customer-side transfer configuration, or use of the service in violation of our Acceptable Use Policy. A failure in our own nameserver infrastructure is not excluded merely because the customer uses Private Master.
  • External customer and resolution paths. Failures of a customer’s internet connection, external recursive resolver or external delegation/registry service where our monitored nameserver infrastructure remains available. Our own service-delivery suppliers remain subject to the responsibility and force-majeure rules above
  • Beta or preview features. Any feature explicitly marked as beta, preview, or experimental is not covered by this SLA

3. Service credits

If we fail to meet the 99.99% uptime commitment in a given calendar month, Enterprise customers are eligible for service credits applied to future invoices or refunded as described below:

Monthly uptime Credit (% of affected service fee)
At least 99.99%No credit
At least 99.9% but below 99.99%10%
At least 99.0% but below 99.9%25%
At least 95.0% but below 99.0%50%
Below 95.0%100%

Reporting an outage. Please report a suspected outage to support@echo-reply.net promptly so that we can investigate. Include your account identifier and, where available, the affected zones and the dates and times when you observed the outage. Prompt reporting is not a separate condition for a credit if you meet the claim deadline below. Your report does not determine the duration of downtime. We assess qualifying downtime using our monitoring data and the evidence-review process in section 1.

Claiming credits. Request the service credit within 30 days after the end of the affected month. Cancellation or termination does not shorten that deadline or extinguish an otherwise eligible claim. We record approved credits when approved, including where an annual subscriber’s next invoice is months away. While the affected subscription continues, we normally apply them as a balance credit to the same billing customer account. That credit may offset any later invoice for that account, including domain or registry charges. We explain this when approving the credit. If that application is not acceptable for the claim, we will instead settle the approved credit by refunding the original payment, with the corresponding credit note and tax adjustment.

Affected service fee. The percentage is applied to the net Enterprise DNS subscription fee actually charged for the affected service period, before VAT. For a full month of an annual Enterprise DNS subscription, the monthly fee is one twelfth of the actual annual fee before VAT. A subscription covered by this SLA for any part of a month is eligible. For a partial month, we use only the prorated net Enterprise fee actually charged for the covered period, excluding time before the subscription starts or after it ends. We account for quantity or plan changes using the applicable invoice lines and do not credit unpaid or unaffected service periods. The calculation excludes Basis subscriptions, one-off domain or registry charges, add-ons, usage charges, taxes, and any other product or service. Any required VAT adjustment is handled on the resulting invoice or credit note under applicable tax rules.

Credit cap. Service credits for one calendar month shall not exceed 100% of the affected service fee for each affected Enterprise subscription. We assess multiple subscriptions separately, with one monthly cap per subscription; caps are not pooled or transferred between subscriptions. Credits are not transferable to another billing customer account. They are settled through invoice credits or the refund alternative described above. Separate incidents in the same month are combined to determine monthly uptime. Only the highest applicable monthly credit band is applied, rather than adding bands or incident credits together. Their durations and credits are not counted more than once.

Credits after termination. If the affected subscription ends and no future invoice remains against which an approved credit can be applied, we will refund the unused approved amount. This also applies to an eligible claim approved after termination, provided it was submitted within the claim deadline. The monthly cap and corresponding tax adjustments continue to apply. We reconcile credits already used or paid and any refund for the same charge to avoid duplicate compensation, without reducing mandatory rights. You do not need to keep an unrelated service or open a new subscription to receive this amount.

Service credits are your sole and exclusive contractual monetary remedy for failure to meet the availability commitment measured under this SLA, subject to section 12 of our Terms of Service and applicable law. This limitation does not exclude liability that cannot lawfully be limited, mandatory consumer rights, or any applicable termination, data-protection, incident-assistance, audit or regulatory-cooperation rights. It does not limit remedies for breach of separate service obligations.

Worked examples

  • Outage confirmation: all five nameservers fail from both locations at 12:00:00, 12:00:30 and 12:01:00, followed by a confirmed recovery at 12:01:30. The counted interval is 90 seconds, not 30 seconds. Two failed observations only span 30 seconds and do not by themselves meet the minimum.
  • Thirty-day month: 4.32 minutes of qualifying downtime produces exactly 99.99% uptime and no credit. Six minutes produces approximately 99.986% uptime and a 10% credit.
  • Monthly Enterprise subscription: a charge of 937.50 DKK including Danish VAT (750.00 DKK excluding VAT) has an affected service fee of 750.00 DKK. At 99.5% uptime, the 25% credit is 187.50 DKK before the corresponding VAT adjustment.
  • Annual Enterprise subscription: a charge of 9,375.00 DKK including Danish VAT (7,500.00 DKK excluding VAT) has a monthly fee basis of 625.00 DKK. At 98.5% uptime, the 50% credit is 312.50 DKK before the corresponding VAT adjustment.

4. Incident communication

We use our public status page to communicate confirmed service incidents when reasonably practicable. Updates may describe current impact, investigation, mitigation, and resolution. We do not promise a fixed publication time, update interval, or post-incident report deadline.

Report a suspected outage or request support at support@echo-reply.net. General service questions may also be sent to info@echo-reply.net. No separate account-manager or escalation mailbox is promised by this SLA.

The outage threshold, exclusions and claim deadline in this SLA apply only to availability credits. They do not determine whether an incident must be investigated or notified under applicable law or another contractual obligation. A partial outage, data-integrity incident or other service failure may require action even when no SLA credit is due. We do not wait for a customer credit claim before assessing those obligations.

How incident scenarios are treated

  • One edge fails: this is an incident, but not qualifying downtime while another monitored nameserver continues to return the expected test-zone response.
  • All edges fail: failure from both monitoring locations qualifies after consecutive observations span 60 seconds. The full interval is counted from the first failed observation to the first confirmed recovery, subject to the exclusions above.
  • Separate failures do not overlap: failures of different edges at different times do not count as qualifying downtime if at least one nameserver continues to pass the test throughout.
  • Customer or Private Master configuration error: a report may help identify the issue, but customer-caused failures are excluded. The independent test zone avoids treating those errors as nameserver-infrastructure outages.

5. Support

Enterprise includes priority support through support@echo-reply.net. Priority means Enterprise requests are triaged ahead of standard requests based on severity and impact. It does not create a fixed first-response or resolution time unless an accepted order says otherwise. This SLA does not promise 24/7 staffed support or define business-hour coverage.

6. Changes to this SLA

Changes to this SLA follow section 13 of the Terms of Service, including its permitted reasons, individual email and in-service notices, minimum 30-day notice for ordinary material changes, and applicable exit rights. Ordinary reductions to the availability commitment, credit protection or paid entitlements take effect no earlier than renewal after sufficient notice. We will honour the current prepaid commitment and preserve accrued credits and claims.

If a replacement agreement requires separate acceptance, the exceptional process in the Terms applies. The existing agreement continues until a notified renewal boundary with at least 60 days’ notice, an initial email, at least two reminder emails and a prominent in-service notice. Failure to acknowledge an ordinary policy notice does not itself interrupt service.

For questions about this SLA, contact support@echo-reply.net or info@echo-reply.net.