> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Getting Help

> Start with your included support agents and carry evidence and findings into human support.

> [!NOTE]
>
> Before running a `tensor9` command, [install the CLI, set `T9_API_KEY`, and verify your customer account](https://docs.tensor9.com/cloud-adapter-early-access/getting-started/install-and-authenticate). Online commands are authenticated and their adapter detail is limited to mappings your account is entitled to use.

Cloud Adapter comes bundled with [support agents](https://docs.tensor9.com/cloud-adapter-early-access/support/agents.md). Start by giving your agent the impact, time window and request path. It helps collect relevant context, work through possible causes and identify the next check. You can ask for help before you know whether an issue belongs to the adapter, the target service or the application.

When human help is needed, use your agreed support channel and bring the agent's findings, evidence references and open questions so the investigation continues from the same context. For an active production incident, use that channel immediately while evidence collection continues. If you do not have one, [contact Tensor9](https://www.tensor9.com/contact/). Your agreement defines incident handling and response terms.

Use [Debugging with Agents](https://docs.tensor9.com/cloud-adapter-early-access/debugging/agents.md) for request behavior, [Tuning with Agents](https://docs.tensor9.com/cloud-adapter-early-access/tuning/agents.md) for performance comparisons and [Operations with Agents](https://docs.tensor9.com/cloud-adapter-early-access/operations/overview.md) for ownership and ongoing coordination.

## Build the investigation with your support agent

Keep the following context with the investigation as it moves from the agent to your team and Tensor9 support. Record missing evidence as an open question; it need not delay escalation.

**1. Record the impact and preserve the original result**

State what is affected, when it started, whether the impact is ongoing and whether there is a safe workaround. Capture the origin operation, status, error code, request identifiers and timestamp with a timezone.

Keep the original result before retrying. A timed-out write may have committed at the target. Do not replay it merely to obtain a cleaner error or an explanation report.

**2. Identify the exact adapter and deployment**

Record the origin and target service identifiers, adapter and SDK versions, deployment shape, configuration revision and affected resource. For DynamoDB, include conditional operations, item sizes, indexes and key distribution when relevant.

Record what changed: a release, target setting, permission, traffic pattern or resource lifecycle event. Keep secrets and customer payloads out of the report.

**3. Inspect the service profile without sending a cloud request**

For an S3 request mapped to Google Cloud Storage, run:

```sh theme={null}
tensor9 explain \
  -origin aws::1.0.0::s3 \
  -target google::1.0.0::gcs \
  -operation PutObject \
  -fmt Human
```

This reads the published profile. It does not start an adapter, call a cloud API or establish what happened to the captured request. Attach the relevant operation description alongside the runtime evidence. See [Using tensor9 explain](https://docs.tensor9.com/cloud-adapter-early-access/debugging/using-explain.md).

**4. Use existing request evidence before making a new request**

Preserve any `x-t9-explain-id` and `x-t9-explain-mode` response headers. Have the authenticated report owner read the existing report and retain its revision, assurance and stated unknowns. A report ID is a locator, not proof that an operation completed or a report was persisted.

Use [Reading an Explanation](https://docs.tensor9.com/cloud-adapter-early-access/debugging/reading-explanations.md) and the [report protocol](https://docs.tensor9.com/cloud-adapter-early-access/debugging/response-headers.md). A report read does not rerun the service operation. Share a permitted, sanitized copy before acknowledging the exact consumable revision.

**5. Choose a bounded reproduction if more evidence is needed**

Prefer an isolated test resource with synthetic data. For covered operations, an explicit signed control can request a non-executing explanation:

```text theme={null}
x-t9-explain: {"version":1,"mode":"Explain","fmt":"Json"}
```

Add the control before SigV4 signing. A completed preview returns a native `ExplainedNotPerformed` service error and a report receipt; retrieve its explanation through `T9CloudAdapter.GetExplanation` on the dedicated synthetic AWS `t9` endpoint, signed as `t9` with the report owner's regular IAM credentials and the report service's configured region. If executing the operation is necessary, get the appropriate approval and use the explicit `ExecuteAndExplain` mode. See [Explaining SDK Requests](https://docs.tensor9.com/cloud-adapter-early-access/debugging/explain-sdk.md).

**6. Correlate the target and send the evidence bundle**

Inspect the relevant target resource and provider metrics for the same time window. Keep target request identifiers, observed throttling, capacity settings and any evidence of a committed write separate from the explanation report.

Have your support agent organize the observations, supported findings and competing explanations into the smallest sanitized bundle that demonstrates the problem. State what remains unknown and what actions you have already taken. Carry that investigation into human escalation without waiting for a complete root-cause analysis.

> [!WARNING]
>
> `x-t9-explain: true` means **ExecuteAndExplain** and can change the target environment. It is not a preview. Neither a missing explanation nor an absent request-effect header establishes that a write had no effect.

[Retrieve an existing report through the signed SDK flow](https://docs.tensor9.com/cloud-adapter-early-access/debugging/explain-sdk.md#retrieve-without-replaying) with the receipt ID, published t9 connection settings and original owner's IAM credentials. Decode the outer AWS JSON response's `body` string, then save and sanitize the rendered report before sharing. This read neither executes the original operation nor acknowledges the report.

## Support request template

Copy this into your support request and omit fields you cannot safely collect:

```text theme={null}
Impact: Orders writes are timing out for one deployment; reads still succeed.
Time window: Include start/end timestamps and timezone.
Adapter: DynamoDB table -> provisioned Cosmos DB.
Operation: UpdateItem with a condition expression.
Versions: Application, SDK, Cloud Adapter and CLI.
Deployment: Environment, deployment shape and configuration revision.
Resource: Sanitized table/container identity and relevant tuning settings.
Workload: Item sizes, operation mix, arrival rate and key distribution.
Original result: Status/error code and origin/target request identifiers.
Explain: Mode, report ID, revision and limitations, when available.
Agent investigation: Question, findings, evidence references and open hypotheses.
Target observations: RU use, throttling, partition pressure and resource state.
Recent changes: Release, configuration, permissions, capacity or traffic.
Actions taken: Reads, retries, rollbacks or tests already performed.
Effect: Confirmed, not observed, or unknown; include the evidence.
Attachments: Redacted configuration and the smallest permitted reproduction.
```

Do not attach credentials, signed URLs, bearer tokens, unrestricted wire logs or production data. Resource names and explanation reports can themselves contain sensitive information. Use the evidence-handling rules agreed for your environment.

## Reporting a performance or scaling issue

Include both request rate and completed-operation rate, errors and latency percentiles over the same interval. Identify object or item sizes and batch sizes. For SQS, distinguish `ReceiveMessage` calls from messages returned: an empty poll can complete correctly without delivering any messages.

Record whether the observation came from steady load, a sudden burst, a rollout or a resource failure. Include relevant scaling activity and configured limits when available. Target latency can consume in-flight capacity even when native target processing is not included in an adapter latency measure.

An example request or Explain report can help locate unexpected work, but it is not a measurement of a monthly SLA. Retain the monitoring window and the measurements used to assess the incident. See [Service Levels](https://docs.tensor9.com/cloud-adapter-early-access/support/service-levels.md) and [Scaling and Limits](https://docs.tensor9.com/cloud-adapter-early-access/support/scaling-and-limits.md).

## Keep access and changes scoped to the investigation

Start with sanitized evidence and give support agents the tools and access appropriate to the question. Authorize live reads, writes, deployment changes and cleanup according to your environment's policy. Keep resource changes, spending and request replay within that scope, and preserve the verification result with the investigation. See [Bounded Work and Approval](https://docs.tensor9.com/cloud-adapter-early-access/operations/bounded-work.md) for coordinating a proposed change.

For the ownership boundary and optional coverage discussions, see [How Support Works](https://docs.tensor9.com/cloud-adapter-early-access/support/overview.md). For pair-specific terms, use the [service-adapter SLA tables](https://docs.tensor9.com/cloud-adapter-early-access/support/service-adapter-slas.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.