1. First Response Time
For all production-impacting incidents reported via our live support chat system, email or voicemail, StoreLocatorWidgets provides an initial human response within 2 hours during our core business hours (08:00–20:00 UTC-4, Monday–Sunday).
Critical-severity issues (service outage affecting all customers) receive a response within 30 minutes.
2. Recovery Point Objective (RPO)
2.1 Data Change Capture
Each time any configuration change is made in the StoreLocatorWidgets administration console, the complete account state (store list, filters, layout settings, API keys, and other configuration objects) is exported as a structured JSON file and written to Amazon S3.
2.2 Multi-Zone and Multi-Region Protection
All JSON snapshots are synchronised to a geographically separate AWS region using AWS S3 Cross-Region Replication (CRR).Snapshots are retained for 90 days, providing a complete point-in-time history of all configuration changes for that period, stored in two independent physical regions.
2.3 Long-Term Recovery
Beyond the 90-day JSON snapshot history, the underlying account database is mirrored to a separate AWS region and is also backed up daily. Monthly backups are stored indefinitely in Amazon S3, replicated across multiple availability zones using S3’s built-in durability model..
2.4 Effective RPO
Because all customer configuration records ultimately rely on Amazon S3 as the authoritative storage layer, the service’s effective RPO is bound by AWS S3’s multi-zone RPO characteristics. For S3 CRR and multi-AZ storage, AWS states that replication typically delivers RPO ≈ 15 minutes for >99.99% of newly written objects.
Therefore StoreLocatorWidgets RPO: ≤ 15 minutes for all account store and configuration data, assuming AWS S3 multi-zone availability. (Reference: https://aws.amazon.com/blogs/storage/designing-a-resilient-and-cost-effective-backup-strategy-for-amazon-s3)
3. Recovery Time Objective (RTO)
3.1 Production Runtime Dependencies
The StoreLocatorWidgets frontend runs entirely on a globally distributed CDN and communicates with a customer-selected mapping provider. Runtime service availability therefore depends on the following external components:
- CDN: BunnyCDN (primary) with Cloudflare as a failover provider
- Mapping provider: Google Maps, Mapbox or ExpressMaps
These dependencies determine the theoretical minimum RTO for a total service interruption.
3.2 CDN Availability and RTO
BunnyCDN
BunnyCDN does not publish a traditional RTO; its SLA is availability-based (99.99%) and relies on automatic edge-node failover and self-healing.
If a CDN node fails, traffic is transparently routed to neighbouring nodes with no service interruption other than a temporary increase in latency. (Reference: BunnyCDN SLA: https://bunny.net/sla/ and Network Map: https://bunny.net/network/
CDN Failover
If BunnyCDN experiences a global material outage exceeding 2 hours, StoreLocatorWidgets technical personnel will execute a manual failover to Cloudflare CDN.
Propagation of the updated CDN endpoint configuration requires up to 300 seconds (5 minutes) due to DNS TTL constraints.
Reverting traffic from Cloudflare back to BunnyCDN requires the same propagation interval.
StoreLocatorWidgets CDN RTO: < 5 minutes once failover is triggered, excluding external provider outage duration.
3.3 Mapping Providers RTO
Google Maps
Google Maps Platform provides a 99.9% uptime SLA for core services, but does not publish a formal RTO. (Reference: https://cloud.google.com/maps-platform/terms/sla).
Mapbox
Mapbox guarantees 99.9% availability, defining unavailability as API inaccessibility for ≥ 2 consecutive 90-second intervals. (Reference: https://www.mapbox.com/legal/sla)
ExpressMaps
ExpressMaps does not publish an RTO or formal SLA.
Impact on StoreLocatorWidgets RTO
The StoreLocatorWidgets frontend degrades gracefully during temporary mapping provider outages. The Store Locator UI, search logic, and configuration retrieval remain functional; however, map tiles may fail to render until the provider restores service.
Since no mapping provider supplies a fixed RTO, the effective RTO for map rendering is dependent on third-party provider restoration times, while core locator logic continues to operate.