> ## Documentation Index > Fetch the complete documentation index at: https://docs.uselayers.com/llms.txt > Use this file to discover all available pages before exploring further. # Incident response overview > How Layers detects, classifies, and communicates about production incidents, including operational recovery targets for the storefront APIs and where to find live status. *Last updated: 2026-09-03.* This page describes how Layers operates when something goes wrong in production. It is an operational overview, not a contractual commitment. Uptime commitments and service credits are defined in the [Service Level Agreement](/legal/service-level-agreement). Reporting a security vulnerability is covered by the [Security disclosure](/legal/security-disclosure) page. ## Detection Layers monitors production continuously. Incidents are most often detected by one of the following before a customer notices: * **Synthetic checks** against the Search and Browse APIs from multiple regions, running every minute. * **Error rate and latency alerting** on the storefront APIs, catalog sync pipeline, and background job queues. * **Infrastructure health monitoring** covering databases, caches, queues, and the edge network, with on-call paging for critical alerts. * **Error tracking** that groups new exceptions and pages the on-call engineer when a new error class appears at volume. * **Customer reports** through [support@uselayers.com](mailto:support@uselayers.com) or the in-dashboard support chat. An on-call engineer is paged for critical alerts 24 hours a day, 7 days a week. ## Severity classification Every incident is assigned a severity when it is opened. Severity drives who is involved, how quickly you hear from us, and how often we update you. | Severity | Definition | Examples | | -------- | ------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | **SEV1** | Storefront search or browse is unavailable or materially degraded for many stores, or a confirmed security incident affecting customer data | API returning errors for a large share of requests; a data exposure | | **SEV2** | A core feature is unavailable or degraded for a subset of stores, or storefront APIs are serving stale or incorrect results | Catalog sync stalled for multiple stores; merchandising rules not applying | | **SEV3** | Non-core functionality is impaired, or a single store is affected with a workaround available | Dashboard analytics delayed; a single integration failing | | **SEV4** | Cosmetic or minor issue with no customer impact on storefront traffic | Dashboard display bug | Severity can be raised or lowered as the investigation progresses. Security incidents are always opened at SEV1 until scope is confirmed. ## Recovery targets Layers operates the production platform against the following targets. They describe how we design and run the service; they are not guarantees and do not replace the terms of the SLA. | Target | Storefront APIs (search, browse, blocks) | Dashboard and catalog sync | | ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Recovery time objective (RTO)** | We target restoring service within 1 hour of a SEV1 being declared | We target restoring service within 4 hours | | **Recovery point objective (RPO)** | We target no loss of configuration data. Storefront traffic is stateless; if events are dropped during an outage they are not replayed | We target at most 24 hours of configuration data loss in a full database restore scenario, and in practice continuous replication keeps this to minutes | The storefront APIs are served from multiple availability zones behind a global edge network, so most infrastructure failures are absorbed without an incident being declared. The catalog mirror can be rebuilt from Shopify at any time, so catalog data is never the limiting factor in a recovery. ## Communication When an incident affects you, here is what to expect: | Severity | First update | Ongoing cadence | Post-incident | | -------- | --------------------------------------------------- | ---------------------------------------- | ---------------------------------------------------------------------------------- | | **SEV1** | Within 30 minutes of declaration on the status page | At least every 60 minutes until resolved | Written post-incident review shared with affected customers within 5 business days | | **SEV2** | Within 1 hour of declaration on the status page | At least every 2 hours until resolved | Summary available on request | | **SEV3** | Affected customers notified through support | As the investigation progresses | On request | | **SEV4** | No proactive communication | Fixed in the normal release cycle | None | Updates go out on the status page first, and to your account contacts by email for SEV1 and SEV2 incidents that affect your store. If you have a dedicated Slack channel with the Layers team, updates are mirrored there. ### Security incidents If Layers confirms a security incident involving your data, we notify your account's security contact without undue delay and in any case within 72 hours of confirmation, with the information needed to meet your own notification obligations. Notifications include what happened, what data was involved, what we have done, and what we recommend you do. ## Status page Live and historical status for the storefront APIs, dashboard, and catalog sync is published at [status.uselayers.com](https://status.uselayers.com). You can subscribe to email or RSS updates from the status page. ## Post-incident review Every SEV1 and SEV2 incident gets a written review covering the timeline, root cause, customer impact, and the changes we are making to prevent recurrence. Reviews are blameless and focus on systems rather than individuals. Action items are tracked to completion. ## Questions For questions about incident handling or to register a security contact for your account, email [support@uselayers.com](mailto:support@uselayers.com). ## Next steps * [Service Level Agreement](/legal/service-level-agreement) for uptime commitments and service credits. * [Security disclosure](/legal/security-disclosure) for reporting a vulnerability. * [Data lifecycle](/legal/data-lifecycle) for backups and retention.