Service level agreements
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.Virtual Machine Scale Sets to EC2 Auto Scaling
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
Foraws::1.0.0::autoscaling::group, a VM scale set maps its desired capacity and machine model into a managed fleet. Autoscaling, health checks and rolling changes use target mechanisms with the profile’s limitations. The request budget covers configuration acceptance; it does not mean that every instance is created, healthy or upgraded within 30 ms. 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
Scale-set configuration acceptance: 30 ms monthly p99.VirtualMachineScaleSets_CreateOrUpdate, VirtualMachineScaleSets_Delete, VirtualMachineScaleSets_Update. Validate the origin request, retain its resource identity and requested configuration, and construct the target change. Adapter-owned metadata and coordination waits remain included.
Rolling upgrade and reimage acceptance: 30 ms monthly p99. VirtualMachineScaleSetRollingUpgrades_StartOSUpgrade, VirtualMachineScaleSets_Reimage. Validate the origin request, retain its resource identity and requested configuration, and construct the target change. Adapter-owned metadata and coordination waits remain included.
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
Scale API handlers and background workers separately. The agreement bounds resource count, concurrent changes, status polling, configuration size and burst growth. More replicas do not remove a shared metadata-store bottleneck or a target API quota. Tensor9 is responsible for adapter capacity within that envelope; the customer supplies target capacity and permissions. Native resource readiness is monitored separately from request acceptance. Limit fleet size, simultaneous rollouts and model size in the agreement. Fleet growth can consume target compute quotas faster than the control API receives requests. Autoscale cooldowns, unhealthy instances and rollout batch policies need their own operational monitoring. 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 supported desired capacity, machine configuration and rollout intent. Do not turn a partial rolling upgrade into a false all-instances-success result. Target-specific overprovisioning and image-update behavior must remain documented. The customer chooses workload health criteria and target capacity; the adapter must retain configuration and report failures accurately.Example and diagnosis
Changeapi-workers from three to five instances and submit a supported image update. Compare request acceptance with subsequent fleet convergence and health. A slow image boot is different from adapter configuration loss or a worker that never applies the accepted model.
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.
Virtual Machine Scale Sets to Managed Instance Group
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
Forgoogle::1.0.0::compute::instance-group-manager, a VM scale set maps its desired capacity and machine model into a managed fleet. Autoscaling, health checks and rolling changes use target mechanisms with the profile’s limitations. The request budget covers configuration acceptance; it does not mean that every instance is created, healthy or upgraded within 30 ms. 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
Scale-set configuration acceptance: 30 ms monthly p99.VirtualMachineScaleSets_CreateOrUpdate, VirtualMachineScaleSets_Delete, VirtualMachineScaleSets_Update. Validate the origin request, retain its resource identity and requested configuration, and construct the target change. Adapter-owned metadata and coordination waits remain included.
Rolling upgrade and reimage acceptance: 30 ms monthly p99. VirtualMachineScaleSetRollingUpgrades_StartOSUpgrade. Validate the origin request, retain its resource identity and requested configuration, and construct the target change. Adapter-owned metadata and coordination waits remain included.
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
Scale API handlers and background workers separately. The agreement bounds resource count, concurrent changes, status polling, configuration size and burst growth. More replicas do not remove a shared metadata-store bottleneck or a target API quota. Tensor9 is responsible for adapter capacity within that envelope; the customer supplies target capacity and permissions. Native resource readiness is monitored separately from request acceptance. Limit fleet size, simultaneous rollouts and model size in the agreement. Fleet growth can consume target compute quotas faster than the control API receives requests. Autoscale cooldowns, unhealthy instances and rollout batch policies need their own operational monitoring. 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 supported desired capacity, machine configuration and rollout intent. Do not turn a partial rolling upgrade into a false all-instances-success result. Target-specific overprovisioning and image-update behavior must remain documented. The customer chooses workload health criteria and target capacity; the adapter must retain configuration and report failures accurately.Example and diagnosis
Changeapi-workers from three to five instances and submit a supported image update. Compare request acceptance with subsequent fleet convergence and health. A slow image boot is different from adapter configuration loss or a worker that never applies the accepted model.
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.