Skip to main content
These terms describe the origin API served by the adapter, not direct calls to the target service. Management-request latency covers accepting and handling the API call; it does not promise that a cloud resource finishes provisioning within that time.

Service level agreements

These tables show Tensor9’s standard service levels and adapters whose standard terms are still being defined. Your signed agreement determines the SLAs, covered adapters and operations, limits, remedies and support terms that apply to your deployment.
Listed terms cover requests sent through this service adapter. They do not cover direct connections to the target service or replace the cloud provider’s own SLA. Each origin-to-target pair has its own terms or an explicit pending status. See the SLA tables, measurement rules, and scaling conditions.

Cloud Storage to S3

Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

What this adapter does

For aws::1.0.0::s3, the adapter receives Cloud Storage JSON API requests and translates object identities, preconditions and native storage calls. Composition uses S3 multipart behavior and refuses source parts that violate its supported minimum-size rules; archival storage can require restore before read. These differences are not hidden by the latency target. These targets describe this adapter design; confirm that your deployment supports the listed operations. A numerical target does not establish runtime availability.

How the latency targets were chosen

Small object requests: 1 ms monthly p99. storage.objects.delete, storage.objects.get, storage.objects.insert. Bounded request translation, precondition mapping and response encoding; large transfers require a byte-rate class. Bounded object composition: 20 ms monthly p99. storage.objects.compose. Validate source identities and ordering, construct multipart/block work and assemble the result. Adapter bookkeeping between target calls remains included. Bucket lifecycle requests: 20 ms monthly p99. storage.buckets.delete, storage.buckets.insert. Bounded configuration validation, durable adapter metadata and response encoding; native provisioning completion and propagation are separate. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

Availability and failures

The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.

Scaling and target-service capacity

Track object bytes, active transfers and composition fan-out independently from request rate. Tensor9 scales translation capacity within the agreed byte, concurrency and part-count limits. Large objects and compose work require memory, bandwidth and metadata headroom. The customer monitors native storage throttling and selects storage classes; adding adapter replicas cannot make an archive object readable before the target restores it. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

Data and behavior guarantees

Preserve object bytes, supported metadata, source ordering and stale-write rejection. A failed compose must not be reported as a successfully committed destination. Generation identifiers are translated identities, not interchangeable native provider counters. Retention policy and notification features outside this directed profile receive no implied coverage. The target’s own durability commitment remains separate.

Example and diagnosis

Reading a 24 KiB reports/summary.json with a supported generation condition uses the small-object row. Composing three acceptable source objects uses the composition row even if the request JSON is tiny. Inspect adapter checksum/identity work separately from native storage waits, and retain the generation values and request IDs without sharing object contents. Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

Cloud Storage to Blob Storage

Deployment availability. These targets describe this adapter design. Confirm that your deployment supports the listed operations; a numerical target does not establish runtime availability. What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

What this adapter does

For azure::1.0.0::blob-storage, the adapter receives Cloud Storage JSON API requests and translates object identities, preconditions and native storage calls. Composition uses Azure block operations, while generation and metageneration conditions must track the version identity exposed back to the application. Client-generated Google signed URLs are not automatically accepted by an Azure endpoint. These targets describe this adapter design; confirm that your deployment supports the listed operations. A numerical target does not establish runtime availability.

How the latency targets were chosen

Small object requests: 1 ms monthly p99. storage.objects.delete, storage.objects.get, storage.objects.insert. Bounded request translation, precondition mapping and response encoding; large transfers require a byte-rate class. Bounded object composition: 20 ms monthly p99. storage.objects.compose. Validate source identities and ordering, construct multipart/block work and assemble the result. Adapter bookkeeping between target calls remains included. Bucket lifecycle requests: 20 ms monthly p99. storage.buckets.delete, storage.buckets.insert. Bounded configuration validation, durable adapter metadata and response encoding; native provisioning completion and propagation are separate. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

Availability and failures

The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.

Scaling and target-service capacity

Track object bytes, active transfers and composition fan-out independently from request rate. Tensor9 scales translation capacity within the agreed byte, concurrency and part-count limits. Large objects and compose work require memory, bandwidth and metadata headroom. The customer monitors native storage throttling and selects storage classes; adding adapter replicas cannot make an archive object readable before the target restores it. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

Data and behavior guarantees

Preserve object bytes, supported metadata, source ordering and stale-write rejection. A failed compose must not be reported as a successfully committed destination. Generation identifiers are translated identities, not interchangeable native provider counters. Retention policy and notification features outside this directed profile receive no implied coverage. The target’s own durability commitment remains separate.

Example and diagnosis

Reading a 24 KiB reports/summary.json with a supported generation condition uses the small-object row. Composing three acceptable source objects uses the composition row even if the request JSON is tiny. Inspect adapter checksum/identity work separately from native storage waits, and retain the generation values and request IDs without sharing object contents. Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

Debug this service

For requests through a service adapter, use Explain and request diagnostics to investigate the selected mapping. Follow the BYOC service-adapter debugging runbook to capture and interpret the diagnostic evidence. Service Catalog.