Skip to main content
Before running a tensor9 command, install the CLI, set T9_API_KEY, and verify your customer account. Online commands are authenticated and their adapter detail is limited to mappings your account is entitled to use.
You can ask for help before you know whether an issue belongs to the adapter, the target service or the application. Start with the impact, the time window and the request path. Missing evidence is something to identify, not a reason to delay reporting a production incident. Use your agreed support channel. If you do not have one, contact Tensor9. Your agreement defines incident handling and response terms.

​
Collect evidence safely

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:
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.
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 and the report protocol. 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:
Add the control before signing. Use an explanation-aware client path because the diagnostic document is not the operation’s ordinary success response. If executing the operation is necessary, get the appropriate approval and use the explicit ExecuteAndExplain mode. See Explaining SDK Requests.
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.Send the smallest sanitized bundle that demonstrates the problem. State what remains unknown and what actions you have already taken. Do not wait for a complete root-cause analysis before reporting the incident.
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.

​
Support request template

Copy this into your support request and omit fields you cannot safely collect:
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 and Scaling and Limits.

​
Support is not a request to grant unrestricted access

Start with sanitized evidence. Any live access, write, deployment change or destructive cleanup needs the authorization appropriate to your environment. A support investigation does not authorize a coding agent or operator to replay customer traffic, raise budgets or change target resources on its own. For the ownership boundary and optional coverage discussions, see How Support Works. For pair-specific terms, use the service-adapter SLA tables.