Service Availability Policy — Delivery Zone
Version: 1.1 Last updated: 2026-05-18 Effective date: 2026-05-13
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 402 responses unless your account status, plan, 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 Postcode Data Disclaimer.