Instaclustr’s service standards are tiered based on the size of the Cassandra cluster that our customer is running. The tiers recognize that larger clusters are able to support more consistent levels of performance and availability.
Tier1
Service Standards2
Customer Requirements
Starter
Developer Nodes
No guaranteed availability4 (99.9% target)
No latency3 SLAs
Minimum replication of 2 on all keyspaces
Add capacity or remove data when requested by Instaclustr to maintain disk usage in normal operations at less than 70%
Comply with reasonable requests from Instaclustr to modify the application for best practice Cassandra usage
Small <=5 production nodes
99.95% availability for LOCAL_QUORUM
No latency SLAs
20% monthly fees at risk in total; 10% credit for each breach
Minimum replication factor of 3 on all keyspaces
(please ensure that cluster is initially configured with target RF of 3)
Add capacity or remove data when requested by Instaclustr to maintain disk usage in normal operations at less than 70%
Comply with reasonable requests from Instaclustr to modify the application for best practice Cassandra usage
Enterprise 6+ production nodes
99.99% availability for LOCAL_QUORUM consistency operations
99% of read/write transactions to Instaclustr-maintained table in the cluster within specified latency threshold3
30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA
Minimum replication factor of 3 on all keyspaces (please ensure that cluster is initially configured with target RF of 3)
Add capacity or remove data when requested by Instaclustr to maintain disk usage in normal operations at less than 70%
Comply with reasonable requests from Instaclustr to modify the application for best practice Cassandra usage
Critical 12+ production nodes
100% availability for LOCAL_QUORUM consistency operations
Custom latency SLA negotiable (or use medium SLA)3
100% of monthly fees at risk in total; 30% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA
Minimum replication factor of 5 on all keyspaces
(please ensure that cluster is initially configured with target RF of 5)
Separate testing and production clusters
Customer notifies that they wish to receive this SLA, commissions Instaclustr to review their application for best practice alignment and actions finding from that review
Instaclustr review prior to deploying changes that may impact latency SLA
Add capacity or remove data when requested by Instaclustr to maintain disk usage in normal operations at less than 70%
Comply with reasonable requests from Instaclustr to modify the application for best practice Cassandra usage
For Enterprise and Critical level Cassandra clusters we also provide Recovery Point Objective SLA: The native replication of data in Cassandra means restoration of data from backups is very rarely required. However, we will maintain backups to allow restoration of data with less than 24 hours data loss for standard backups and less than 5 minutes data loss for our Continuous Back-ups option. Should we fail to meet this recovery point objective, you will be eligible for SLA credits at 100% of monthly fees for the relevant cluster. If you have undertaken to restore testing of your cluster in the last 6 months (using our automated restore functionality) and can demonstrate that data loss during an emergency restore is outside target RPO and your verification testing, then you will be eligible for SLA credits at 500% of monthly fees.
Kafka Services
Instaclustr’s service standards are tiered based on the size of the Kafka cluster that our customer is running. The tiers recognize that larger clusters are able to support more consistent levels of performance and availability.
Tier1
Service Standards2
Customer Requirements
Starter Developer Nodes11
No guaranteed availability4 (99.9% target)
No latency3 SLAs
Minimum replication of 2 on all topics
Add capacity or adjust retention settings when requested by Instaclustr to maintain disk usage in normal operations as less than 80%
Comply with reasonable requests from Instaclustr to modify application for best practice Kafka usage
Small <=5 production nodes
99.95% availability for writes with 2 replica consistency requirement and all reads
No latency SLAs
20% monthly fees at risk in total; 10% credit for each breach
Minimum replication of 3 on all topics
Add capacity or adjust retention settings when requested by Instaclustr to maintain disk usage in normal operations as less than 80%
Comply with reasonable requests from Instaclustr to modify application for best practice Kafka usage
Enterprise 6+ production nodes
99.99% availability for writes with 2 replica consistency requirement and all reads
Availability SLA is increased to 99.999% when dedicated ZooKeeper nodes are used
99% of read/write transactions to Instaclustr-maintained topic in the cluster within specified latency threshold3
30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA
Minimum replication factor of 3 on all topics
Add capacity or adjust retention settings when requested by Instaclustr to maintain disk usage in normal operations at less than 80%
Comply with reasonable requests from Instaclustr to modify the application for best practice Kafka usage
Critical 12+ production nodes
99.999% availability for writes with 2 replica consistency requirement and all reads
99% of read/write transactions to Instaclustr-maintained topic in the cluster within specified latency threshold3
100% of monthly fees at risk in total; 30% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA
Minimum replication factor of 3 on all topics
Separate testing and production clusters
Must use dedicated ZooKeeper nodes for production
Customer notifies that they wish to receive this SLA, commissions Instaclustr to review their application for best practice alignment and actions findings from that review
Instaclustr review prior to deploying changes that may impact latency SLA
Add capacity or remove data when requested by Instaclustr to maintain disk usage in normal operations at less than 80%
Comply with reasonable requests from Instaclustr to modify application for best practice Kafka usage
Kafka Connect Services
Instaclustr’s service standards are tiered based on the size of the Kafka Connect cluster that our customer is running. The tiers recognize that production clusters are able to support more consistent levels of performance and availability.
Tier1
Service Standards2
Customer Requirements
Starter Developer Nodes11
No guaranteed availability8 (99.9% target)
Add capacity as reasonably requested by Instalcustr to manage operational loads.
Comply with reasonable requests from Instaclustr to modify the application for best practice Kafka Connect usage
Production Nodes
99.99% availability8 to Instaclustr maintained synthetic transaction connector
20% monthly fees at risk in total; 10% credit for each breach
Minimum of 3 nodes
Add capacity as reasonably requested by Instalcustr to manage operational loads.
Comply with reasonable requests from Instaclustr to modify the application for best practice Kafka Connect usage
Elasticsearch Services
Instaclustr’s service standards are tiered based on the size of the Elasticsearch cluster that our customer is running. The tiers recognise that larger clusters are able to support more consistent levels of performance and availability.
Tier1
Service Standards2
Customer Requirements
Starter
Developer Nodes
No guaranteed availability (99.9% target)
No latency3 SLAs
Minimum of one replica shardon all indexes
Add capacity or adjust retention settings when requested by Instaclustr to maintain disk usage in normal operations as less than 70%
Comply with reasonable requests from Instaclustr to modify the application for best practice Elasticsearch usage
Small
<=6 production nodes
99.95% availability for writes at Quorum with and all reads
No latency SLAs
20% monthly fees at risk in total; 10% credit for each breach
Minimum of 2 replica shards on all indexes
Use dedicated masters
Add capacity or adjust retention settings when requested by Instaclustr to maintain disk usage in normal operations as less than 70%
Comply with reasonable requests from Instaclustr to modify the application for best practice Elasticsearch usage
Enterprise
7+ production nodes
99.99% availability for writes at Quorum and all reads
95% of read/writes to Instaclustr-maintained index in the cluster within specified latency threshold3
30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA
Minimum of 2 replica shards on all indexes
Use dedicated masters
Add capacity or adjust retention settings when requested by Instaclustr to maintain disk usage in normal operations at less than 70%
Comply with reasonable requests from Instaclustr to modify the application for best practice Elasticsearch usage
Critical
12+ production nodes
99.999% availability for writes at Quorum and all reads
99% of read/writes to Instaclustr-maintained index in the cluster within specified latency threshold3
30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA
Minimum of 2 replica shards on all indexes
Use dedicated mastersSeparate testing and production clusters
Customer notifies that they wish to receive this SLA, commissions
Instaclustr to review their application for best practice alignment and actions findings from that review
Instaclustr review prior to deploying changes that may impact latency SLA
Add capacity or remove data when requested by Instaclustr to maintain disk usage in normal operations at less than 70%
Comply with reasonable requests from Instaclustr to modify the application for best practice Elasticsearch usage
Redis Services
Instaclustr’s service standards are tiered based on the class of the Redis cluster that our customer is running. The tiers recognise that production clusters are able to support more consistent levels of performance and availability.
Tier1
Service Standards2
Customer Requirements
Starter
Developer Nodes
No guaranteed availability (99.9% target)
No latency3 SLAs
Add capacity as reasonably requested by Instalcustr to manage operational loads.
Comply with reasonable requests from Instaclustr to modify the application for best practice Redis usage
Enterprise
6+ production nodes
99.99% availability9 to Instaclustr maintained synthetic transaction
30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA
The number of Redis Replica Nodes is greater than or equal to the number of Redis Master Nodes
Add capacity as reasonably requested by Instalcustr to manage operational loads.
Comply with reasonable requests from Instaclustr to modify the application for best practice Redis usage
ZooKeeper Services
Instaclustr’s service standards are tiered based on the class of the Apache ZooKeeper cluster that our customer is running. The tiers recognise that production clusters are able to support more consistent levels of performance and availability.
Tier1
Service Standards2
Customer Requirements
Starter
Developer Nodes
No guaranteed availability (99.9% target)
No latency3 SLAs
Add capacity as reasonably requested by Instalcustr to manage operational loads.
Comply with reasonable requests from Instaclustr to modify the application for best practice ZooKeeper usage
Enterprise
3 or more production nodes
99.99% availability 10
No latency3 SLAs
30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA
Add capacity as reasonably requested by Instalcustr to manage operational loads.
Comply with reasonable requests from Instaclustr to modify the application for best practice ZooKeeper usage
PostgreSQL Services
Instaclustr’s service standards for PostgreSQL are tiered based on the size, and number of nodes in the PostgreSQL cluster that our customer is running. The tiers recognize that production instances are able to support a more consistent level of performance and availability.
Tier
Service Standards
Customer Requirements
Starter
(Developer Nodes)
No guaranteed availability (targeting 99.95%^12)
No latency SLAs
Add capacity as reasonably requested by Instalcustr to manage operational loads.
Configure cluster replication and query settings which are appropriate for their data loss tolerance ^13
Comply with reasonable requests from Instaclustr to modify the application for best practice PostgreSQL usage
Enterprise
2+ production nodes
99.99%^12 availability for read and write operations
99.9%^3 of read/write transactions to Instaclustr-maintained table in the cluster within specified latency threshold
30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA
Add capacity as reasonably requested by Instalcustr to manage operational loads.
Comply with reasonable requests from Instaclustr to modify the application for best practice PostgreSQL usage
Configure cluster replication and query settings which are appropriate for their data loss tolerance ^13
**Availability uptime is not inclusive of one 30 minute scheduled maintenance window per month. Customers will be notified of scheduled maintenance at least 7 days in advance, and Instaclustr will make all reasonable attempts to minimise the impact to your availability.
OpenSearch Services
Instaclustr’s service standards are tiered based on the size of the OpenSearch cluster that our customer is running. The tiers recognise that larger clusters are able to support more consistent levels of performance and availability.
Tier1
Service Standards2
Customer Requirements
Starter
Developer Nodes
No guaranteed availability (99.9% target)
No latency3 SLAs
Minimum of one replica shard on all indexes
Add capacity or adjust retention settings when requested by Instaclustr to maintain disk usage in normal operations at less than 70%
Comply with reasonable requests from Instaclustr to modify application for best practice OpenSearch usage
Small
<=6 production nodes
99.95% availability for writes at Quorum with and all reads
No latency SLAs
20% monthly fees at risk in total; 10% credit for each breach
Minimum of 2 replica shards on all indexes
Use dedicated masters
Add capacity or adjust retention settings when requested by Instaclustr to maintain disk usage in normal operations at less than 70%
Comply with reasonable requests from Instaclustr to modify the application for best practice OpenSearch usage
Enterprise
7+ production nodes
99.99% availability for writes at Quorum and all reads
95% of read/write transactions to Instaclustr-maintained topic in the cluster within specified latency threshold3
30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA
Minimum of 2 replica shards on all indexes
Use dedicated masters
Add capacity or adjust retention settings when requested by Instaclustr to maintain disk usage in normal operations at less than 70%
Comply with reasonable requests from Instaclustr to modify the application for best practice OpenSearch usage
Critical
12+ production nodes
99.999% availability for writes at Quorum and all reads
99% of read/write transactions to Instaclustr-maintained topic in the cluster within specified latency threshold3
30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing a breach of latency SLA
Minimum of 2 replica shards on all indexes
Use dedicated masters
Separate testing and production clusters
Customer notifies that they wish to receive this SLA, commissions Instaclustr to review their application for best practice alignment and actions findings from that review
Instaclustr review prior to deploying changes that may impact latency SLA
Add capacity or remove data when requested by Instaclustr to maintain disk usage in normal operations at less than 70%
Comply with reasonable requests from Instaclustr to modify the application for best practice OpenSearch usage.
SLA tier is per-cluster and based on the number of nodes in the cluster. Customer credits are calculated based on the fees payable for the cluster or clusters impacted by the incident. SLAs credits apply to production clusters only.
Service levels are measured on a monthly basis based on Instaclustr’s monitoring systems. All service levels exclude outages caused by non-availability of service at the underlying cloud provide region level or availability zone level in regions which only support two availability zones.
Latency is measured at a minimum rate of one read/write pair per node per 20 second period. Latency SLA excludes incidents where the cause is determined to be changes to a customer’s application or unusually high loads on the cluster.
Availability is measured by Instaclustr’s synthetic monitoring at a minimum rate of one read/write pair per node per 20 second period. A cluster is considered to be unavailable where read/write operations fail for a majority of nodes in the cluster in a given check-in period.
Where a customer meets requirements for a tier based on cluster size but does not meet other requirements for a tier, the highest level of SLA where all requirements are met will apply.
All SLAs exclude issues caused by customer actions including but not limited to attempting to operate a cluster beyond available processing or storage capacity.
SLA credits must be claimed by customers within 14 days of the end of the relevant calendar month.
For Kafka Connect, Availability is measured by Instaclustr’s synthetic monitoring at a minimum rate of one Connector read or write operation per cluster per 20 second period. Excludes issues caused by BYO Kafka Connect Connectors due to the potential impact of user code on the availability of these environments.
For Redis, availability is measured by Instaclustr’s synthetic monitoring at a minimum rate of one read or write operation per cluster per 20 second period. Excludes latency issues caused by the use of integrated Lua scripting (EVAL and EVALSHA). Excludes issues caused by customers executing commands marked as “dangerous” by the Redis project (turning on authentication will restrict access to these commands). Details of these commands can be found here.
For ZooKeeper, availability is measured by establishing a connection with the ZooKeeper server on each node using a local ZooKeeper client, on a per node per 20 second basis.
For preview versions of Kafka and Kafka Connect, only their respective “Starter” tier SLAs are valid. Production usage may be brought under an agreed SLA for the GA version after joint testing. Please contact us if you wish to discuss this option.
PostgreSQL Availability is measured by Instaclustr’s synthetic monitoring at a minimum rate of one read/write pair per node per 20 second period. A cluster is considered to be unavailable where read/write operations fail for all nodes in the cluster in a given check-in period.PostgreSQL SLAs exclude issues caused by customer actions including but not limited to; attempting to operate a cluster beyond available processing or storage capacity, modifications to application configuration, or customer initiated reloads or resizes.
PostgreSQL uptime is not inclusive of one 30 minute scheduled maintenance window per month. Customers will be notified of scheduled maintenance at least 7 days in advance, and Instaclustr will make all reasonable attempts to minimise the impact to your availability.
Client PostgreSQL applications should be configured in order to maintain high availability, and reestablish connections in the event of a master replica failure. For more information see Replication and High Availability
Other Services
Instaclustr does not currently provide availability or latency SLAs for additional services such as Apache Spark. This is primarily due to the potential impact of user code on the availability of these environments. Should you require an SLA for a specific usage of these tools then please contact us via our support channels to discuss a custom SLA.
