Skip to main content

SLA and Limits

This article covers the availability and performance expectations of Salted CX.

SLA​

We target the availability of 99% percent.

The SLA does not cover:

  • Unavailability of the data caused by the original data source unavailability.
  • Data load delays caused by the performance and limits of the data source.
  • Data load delays caused by bulk updates in the original data source.
  • Data load delay of less than 3 hours.
  • Planned maintenance windows.

Maintenance Window​

From time to time Salted CX undergoes planned maintenance windows. We announce our maintenance windows 72 hours before they are planned and target the off-peak hours for the customers. During planned maintenance, some or all of our functionality may not be available.

Check our status page for the current Salted CX status and planned maintenance windows.

Load Frequency​

We load data incrementally in 15-minute intervals for data sources that enable such incremental loads. Data for a given 15-minute interval will be available sometime during the following 15-minute time interval. The longest delay for regular data loads is then 30 minutes. For example, a conversation starting at 8:00 AM is loaded sometime between 8:15 AM and 8:30 AM. We do not guarantee the exact time in the time interval when the load happens.

See Data Loads for detailed information on how data are loaded in Salted CX.

Data Retention​

Salted CX keeps metadata and content for at least two years. Salted CX can delete data older than two years to maintain performance. Customers can agree with Salted CX on longer minimum retention period.

Visualization Rendering Performance​

Typically visualizations take a few seconds to render. Salted CX does not provide a guaranteed time it takes to render visualizations. Users can create custom metrics and visualizations based on any metric and attribute in our Logical Model which makes it very extremely difficult to guarantee performance.

Factors that have a major influence on the performance:

  • Metric complexity.
  • Size of data used by the visualization.
  • The total size of the metadata.
  • Number of concurrent users.

Disaster Recovery​

In rare instances such as large-scale hardware failure and a combination of multiple human errors, data loss may occur in Salted CX.

Design for Disaster Recovery​

We extensively backup data to facilitate recovery in case there is a wide-scale hardware failure in the production environment.

  • Primary Storages. Primary storages use replication to improve performance and reliability.
  • Ingest Storage. Ingest Storage is designed to be the primary recovery point for most scenarios. Extractor storage is designed to keep data in the format closest to the format as received from the data sources to minimize the chances of application code losing or modifying important data points. The underlying storage technology is designed for 99.999999999% durability and 99.99% availability of each file over one year.
  • Ingest Storage Backup. Ingest Storage is backed every 24 hours into a separate storage called Ingest Storage Backup. The primary reason for this backup is to minimize the chances of human errors, bugs in application code, and improper setup causing unrecoverable loss of data.
  • Original data source. We can use the original data source as a last resort to recover in case of catastrophic loss of all backup solutions on our side. This option is not available for all data sources as they do not store the data historically with enough granularity. Recovery from the original data source may be slower due to data source limits and thus not fit into the Recovery Point Objective. Also, Recovery from the original data source may cause loss of granularity and accuracy in the data. It is equivalent to Salted CX being enabled from the moment of the data recovery. Check Historical Changes in Salted CX for more details.
note

We use the data sources in read-only mode (we only extract data). Our application does not do any write or delete operations into your data sources. Our instructions for the setup of data sources also encourage giving us the least required privileges with read-only access. This minimizes the chances of any data loss in the data source caused by us.

Recovery Point Objective​

The Recovery Point Objective (RPO) tells how much recent data can be lost without having critical impact on business continuity. It is expressed in time and influences how often backups are performed.

Salted CX targets the Recovery Point Objective of 24 hours.

Recovery Time Objective​

The Recovery Time Objective (RTO) tells how long it takes to recover data in an event of a disaster recovery.

Salted CX targets the Recovery Time Objective of 24 hours for conversations that happened in the last 30 days. Data related to conversations that happened more than 30 days ago may take longer to recover and Salted CX would keep the customer informed about the progress.

Customer Responsibilities​

To ensure we can perform disaster recovery we may require the customer to cooperate.

These responsibilities include:

  • Keep data in the data source for the time period supported by Salted CX. If the data source stores historical data, keep the historical available in the original system as the last resort recovery option.
  • Keep the data sources available and accessible. Ensure that we can access the data source for data recovery purposes.
  • Guarantee limits and bandwidth from the data source. For recovery purposes, the load on the data source will be significantly higher than during regular loads. Limits and bandwidth impact recovery time. The limits and bandwidth have to take into consideration other services Salted CX shares these resources with.
  • Keep privileges to the data source restricted to the minimum required for data extraction. This ensures that Salted CX does not