> ## Documentation Index > Fetch the complete documentation index at: https://docs.amlok.io/llms.txt > Use this file to discover all available pages before exploring further. # Service level agreement > AMLOK's standard availability commitment, support response targets, and handling of service concerns. This page describes AMLOK's standard SLA for paid production services. It applies when included in your service agreement. A signed agreement with different terms takes precedence. Your account manager can confirm the services and coverage included in your agreement. ## Availability commitment The monthly availability target is **99.9%** for covered AMLOK production services: API access, Insights processing, Signal monitoring, reporting, and webhook delivery. Coverage applies to the AMLOK-controlled service, not a guarantee of upstream provider availability or completion of every individual analysis within a fixed time. Availability is measured separately for each covered service over each calendar month in UTC: `Monthly availability = 100 × (eligible service minutes - unavailable minutes) / eligible service minutes` Eligible service minutes are the minutes the service is in scope for your agreement during the month, excluding the periods below. A minute is unavailable when an AMLOK-controlled failure prevents the service's core function for the affected workspace, supported by monitoring or verified incident evidence. Overlapping incidents count once. If there are no eligible service minutes, no availability percentage is calculated. The [healthcheck](https://docs.amlok.io/api-reference/endpoints/platform/healthcheck.md) and [service status](https://docs.amlok.io/api-reference/endpoints/platform/service-status.md) endpoints help with incident detection. A successful healthcheck alone does not prove that an asynchronous workflow, data refresh, or individual webhook has completed. ## Support response targets | Priority | Business impact | Initial human response | Coverage | | - | - | - | - | | P1 - Critical | Production unavailable or a critical workflow blocked with no reasonable workaround. | Within 1 hour | 24/7 | | P2 - High | Major degradation or a key function impaired; operations can continue with a workaround. | Within 4 business hours | Business hours | | P3 - Normal | Limited functional issue or integration defect without broad production impact. | Within 1 business day | Business hours | | P4 - Low | General guidance, documentation, feature request, or routine account question. | Within 2 business days | Business hours | Business hours are **Monday to Friday, 9:00 a.m. to 5:00 p.m. Eastern Time**, excluding Canadian federal statutory holidays. One business day is eight covered hours. The response clock starts when the request reaches [support@amlok.tech](mailto:support@amlok.tech); for P2-P4, only covered business time counts. A human response acknowledges the reported impact and provides an investigation step or requests necessary information. Automatic email replies do not satisfy this target. These are initial-response targets, not guaranteed resolution times. AMLOK communicates restoration estimates when there is enough evidence to make them useful. For P1 incidents, keep an authorized technical contact available while recovery is in progress. If the impact changes, AMLOK and your contact reassess the priority. See [severity and escalation](https://docs.amlok.io/support/severity-and-escalation.md) for updates and escalation. ## Maintenance and exclusions AMLOK aims to provide at least **48 hours' notice** for planned maintenance that affects covered services. Emergency maintenance may require shorter notice; AMLOK communicates the impact and progress as soon as practical. The availability calculation excludes only the directly affected period attributable to: * Announced planned maintenance or necessary emergency maintenance. * Customer configuration, credentials, infrastructure, unauthorized use, or requests outside the agreed limits. * External banks, data providers, or networks outside AMLOK's control. An AMLOK failure handling an otherwise available provider is not excluded simply because a provider is involved. * Customer-requested suspension, or suspension permitted by the agreement. * Sandbox, preview, or experimental features unless expressly covered in the agreement. * Events outside reasonable control as defined in the agreement. Expected asynchronous processing, missing borrower permission, and provider refresh schedules are not themselves service outages. Material AMLOK service failures remain assessable under the core-function definition above. ## Service concerns and discretionary remedies Report service concerns to [support@amlok.tech](mailto:support@amlok.tech) with the workspace, incident references, affected workflow, and redacted evidence. There is no standard compensation schedule, automatic service credit, or formula-based payout for an availability or response-target miss. AMLOK may consider a remedy at its discretion. Any compensation must be expressly agreed with AMLOK; reporting an incident does not by itself create an entitlement to compensation. This is separate from the full unused-credit refund on [account cancellation](https://docs.amlok.io/pricing/refunds-and-payouts.md). That cancellation policy continues to apply. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.