Skip to main content
These pages describe Tensor9’s standard service levels. Your signed agreement determines the SLAs, covered adapters and operations, limits, remedies and support terms that apply to your deployment.
Cloud Adapter support covers the service adapter between your application’s origin API and its selected target service. Tensor9 helps you select that adapter, understand its behavior, tune supported settings and investigate requests. You do not need to prove which system is at fault before asking for help. A service adapter is a directed pair, such as S3 to Google Cloud Storage or DynamoDB to provisioned Cosmos DB. A commitment for one pair does not automatically apply to another backend, every operation of the origin service, or every deployment shape.

​
The standard support model

The standard model separates the Tensor9 request path from the native target service. Your application remains responsible for its workload and the target resources it uses; Tensor9 remains responsible for the adapter behavior covered by your agreement. A target capacity setting is not an adapter capacity setting. For example, a provisioned Cosmos DB container’s RU/s maximum controls the target resource. It does not specify how many conditional DynamoDB updates the adapter can complete each second. See Scaling and Limits.

​
What the adapter boundary includes

The boundary does not end permanently when the first target request is sent. An origin operation can require work before the target call, between several target calls and after the target responds. The adapter commitments cover Tensor9 processing in those stages: interpreting the origin request, evaluating authorization, translating operations, coordinating work and producing the origin-shaped response. Native target-service processing is a separate dependency. See Service Levels for measurement boundaries and attribution. A target error is not automatically outside Tensor9’s responsibility. If an adapter defect constructed the wrong request, applied a tuning directive incorrectly or mishandled a valid response, the fact that a target service participated does not excuse the defect. Conversely, a correct translation cannot make a target quota increase or a native provider outage disappear.

​
Example: S3 to Google Cloud Storage

Suppose an application’s PutObject requests become slow. Preserve a few request identifiers and compare the same time window across the application, adapter and Google Cloud Storage observations.
  • Slow request preparation or response handling belongs in the adapter investigation.
  • Native storage latency, target permissions and account quotas belong in the target investigation.
  • Retries, object sizes and client upload time can change the application’s observed latency without representing the same change in adapter processing.
Tensor9 can help investigate all three. The applicable SLA determines which measured part of the path is covered, not whether you may open a support request. Read the S3 to GCS SLA example and S3 tuning guide.

​
Example: DynamoDB to provisioned Cosmos DB

For an UpdateItem workload on an orders table, record whether requests use conditions, the item sizes, key distribution and selected indexes. Those details affect the adapter’s work and the native request load. Inspect the actual Cosmos DB container’s RU consumption, throttling and partition distribution. An account-wide average can hide pressure on one partition. If the native resource needs more capacity or a different data layout, you own that choice with Tensor9’s help. If the adapter introduces unexpected calls or does not honor documented behavior, that is an adapter issue to investigate. Do not assume that increasing either target RU/s or adapter replicas necessarily resolves both bottlenecks. Use the DynamoDB to Cosmos DB SLA example, trade-offs and tuning guide together.

​
Coverage follows your deployment and agreement

An SLA-backed production deployment, a self-operated cluster and a local single binary have different operating boundaries. Starting the binary in a quickstart does not activate a production availability or scaling commitment. Check the deployment, exact operation set, workload limits, measurement window and remedies in your agreement. The service-adapter SLA tables bring the pair-specific terms together. API compatibility, a measured maximum operating rate, an availability objective and an incident response time are different statements. None should be inferred from another. If you need an arrangement extending beyond the standard adapter boundary, contact Tensor9 to discuss it. Any additional coverage must be defined in your agreement; it is not included by implication in the standard model.

​
Ask for help

Use your agreed support channel, or contact Tensor9. Include the business impact and the smallest useful evidence bundle. Response and escalation terms come from your support agreement; this article does not establish a universal response-time commitment. Getting Help walks through safe evidence collection with tensor9 explain and x-t9-explain.