---
title: "Service Availability Policy"
product: "Delivery Zone"
version: "1.2"
last_updated: "2026-08-31"
effective_date: "2026-08-31"
status: "current"
---
Service Availability Policy — Delivery Zone
Version: 1.2
Last updated: 2026-08-31
Effective date: 2026-08-31
---
1. Intent, Not a Binding SLA
We aim to provide a reliable, high-availability service. However, we do not currently offer a
legally binding Service Level Agreement (SLA) with financial penalties or service credits.
This policy describes our operational commitments and how we handle planned and unplanned
downtime.
If you require a formal SLA with contractual service credits, contact us at
[email protected] to discuss custom arrangements — this may be available to higher-tier
plan customers.
---
2. Target Availability
We use 99.5% monthly availability as an internal operational target for the API and
dashboard, excluding scheduled maintenance windows. This target is not a contractual SLA and
does not create automatic rights to refunds, service credits, or damages.
Availability is measured based on our internal monitoring of the production API and dashboard,
not on individual customer network paths, client-side errors, or third-party incidents outside
our reasonable control.
We aim to keep the public delivery check API available at all times, including during
dashboard maintenance windows where possible.
Any refund request related to service unavailability is handled under the
Billing & Refund Policy and is assessed case by case.
---
3. Scheduled Maintenance
Where possible, we schedule maintenance during low-traffic hours (typically 01:00–05:00
Finland time, Europe/Helsinki).
We will provide at least 24 hours' advance notice via in-app announcement or email for any
planned maintenance expected to cause more than 5 minutes of API or dashboard downtime. For
minor maintenance (expected impact under 5 minutes), we may not provide advance notice but
will log it as a maintenance event.
We may perform emergency maintenance without advance notice where necessary to address security
issues, abuse, data integrity risks, provider incidents, or urgent operational problems.
---
4. Incident Response for Unplanned Outages
When an unplanned outage or significant degradation is detected, we will investigate and work
to restore service as quickly as possible.
We do not currently operate a formal status page or committed incident response-time SLA.
Where appropriate, we may notify affected customers by email after a significant incident.
If you experience an outage, contact [email protected].
---
5. What Is Excluded from Availability Commitments
The following are outside the scope of any availability commitment:
- Downtime caused by factors outside our reasonable control (force majeure events, including natural disasters, civil unrest, widespread internet outages, war).
- Downtime resulting from third-party infrastructure provider outages that we cannot reasonably mitigate.
- Downtime caused by customer misuse, excessive traffic beyond plan limits, or violations of the Acceptable Use Policy.
- Brief service degradation during auto-scaling events, rolling deployments, or health-check restarts.
- Unavailability caused by customer-side network, integration, or configuration issues.
- Trials, preview features, and limited-access features, which are provided without any availability commitment.
---
6. Third-Party Provider Dependencies
The Service depends on third-party providers for hosting, database, CDN/security, payments,
and transactional email. Outages or degraded performance at these providers may affect parts
of the Service.
Payment-provider outages may affect billing or dashboard subscription management without
necessarily affecting the delivery check API. Transactional-email outages may affect account
verification, password reset, or billing notifications without necessarily affecting the
delivery check API.
We have no contractual ability to commit to availability metrics beyond our own hosting tier.
---
7. Trials, Preview Features, and Limited Access
Free trials, promotional access, private beta access, preview features, and early-access
features may be changed, limited, suspended, or withdrawn at any time. Unless expressly agreed
otherwise in writing, these features are provided without any availability commitment.
---
8. Customer Responsibility
We recommend that you:
- Implement appropriate error handling and retry logic in your API integration.
- For business-critical delivery decisions, implement a fallback or manual override process rather than relying solely on the Delivery Zone API.
- Maintain your own records of delivery zone configuration, independent of the dashboard.
For 429 responses, use exponential back-off and respect any Retry-After header where
provided. Do not repeatedly retry a DAILY_LIMIT_EXCEEDED or PLAN_LIMIT_EXCEEDED response
unless your account status, plan, key, or quota has changed. For 5xx responses, use
reasonable retry limits and fallback handling.
Postcode check results reflect your configured rules and current reference data; they may not
represent actual delivery capability in all edge cases. See the
---