What If Amazon Bedrock AgentCore Trace Data Is Missing in 2026?

AWS documents three distinct AgentCore telemetry types: metrics, logs, and traces (AgentCore observability documentation). If trace data is missing, don’t treat that as proof that all CloudWatch logging has failed. First confirm the account, Region, Runtime resource, and query window; then check CloudWatch Transaction Search, the resource’s telemetry configuration, and the permissions and destination used to deliver data. If your agent runs outside AgentCore Runtime, also verify its OpenTelemetry instrumentation.

Who this is for: You have deployed an agent to AgentCore Runtime but lack useful trace details when a request fails. You configure CloudWatch telemetry for Runtime, Memory, or Gateway resources. You need a repeatable way to capture and share production troubleshooting evidence.

Start by identifying what is actually missing

“Nothing in CloudWatch” can describe different failures. An invocation error is not the same as an absent log, and a log without spans does not necessarily indicate a failed Runtime deployment. Separate the symptoms before changing settings; otherwise, you may add instrumentation when the actual issue is the query scope, or change permissions when the resource never had the relevant telemetry enabled.

Use this order for the first pass:

• Confirm the account and Region. Make sure the console is showing the account where the Runtime or other AgentCore resource exists. Check the Region independently; a query in the wrong Region can look like a delivery failure.
• Confirm the resource. Match the Runtime or other resource you are investigating to the one that handled the request. Check the resource identifier and environment, especially if you have separate development and production deployments.
• Set a query window around a known request. Use a request you can identify by its approximate time or correlation details. A broad or stale window makes it harder to tell whether data is absent or simply outside the search.
• Classify the missing signal. Record whether the invocation failed, logs are absent, traces are absent, or only some telemetry is present.

Why can CloudWatch show no AgentCore trace even when the agent ran? A successful invocation does not, on its own, establish that trace search is enabled, that the resource emits spans, or that telemetry reached the destination you queried. Treat invocation outcome and trace availability as separate checks. The AgentCore observability guide explains the setup path; use it alongside the resource’s current configuration rather than inferring trace delivery from the application response.

Check Transaction Search before changing the agent

CloudWatch Transaction Search and resource-level telemetry settings are related, but they answer different questions. Transaction Search affects whether traces can be found through that search workflow. Resource configuration determines which telemetry a given AgentCore resource emits and where it sends it. Checking only one layer can leave the same symptom unresolved.

Start with the CloudWatch Transaction Search enablement instructions. Verify that the setting is enabled for the account and Region you are querying, and confirm that you followed the current first-time setup requirements. Then check the resource’s telemetry settings separately. Don’t assume that enabling a CloudWatch account-level feature automatically turns on every Runtime, Memory, or Gateway signal.

After you make a change, send a new, identifiable request and query for that request. Allow for ingestion and indexing to complete, but don’t turn an example wait time in documentation into a delivery guarantee for every account, Region, or workload. If a new request still has no trace results, preserve the request time and resource identifier, then continue with the destination and permission checks.

For Runtime spans, verify that you are looking in the appropriate CloudWatch view. AWS documents where Runtime spans appear in its AgentCore observability view guide. A search in the wrong view or through the wrong workflow can make available spans appear missing.

Match the signal to the resource

Don’t assume every AgentCore resource emits the same data by default. Check the resource type, the signal you expect, the resource’s telemetry configuration, and its destination. For detailed configuration, use the current AgentCore observability configuration reference; it is safer than copying an older example without checking whether its resource type and destination match your deployment.

Use the Runtime telemetry reference to distinguish documented Runtime metrics from trace expectations. Metrics being present does not establish that spans are enabled or searchable. Similarly, a log destination setting should not be taken as evidence that traces have the same configuration or delivery path.

AWS documentation and release notes can change. Before relying on a saved command, policy, or destination name, compare it with the current AgentCore release notes and the configuration reference. Destination assumptions copied from an older deployment can misdirect an otherwise valid investigation.

Use the symptom to choose the next check

The following matrix is a diagnostic guide, not a claim that one symptom has only one cause. Check the evidence in the order shown, and record what you find before making changes.

Should you check permissions or the log destination first? Check them as a pair after confirming the resource is configured to emit the signal. The destination tells you where data should go; the relevant permissions determine whether the service or application can deliver it there. If configuration points to an unexpected destination, fix that mismatch. If it points to the intended destination but nothing arrives, inspect the applicable permissions and delivery errors. For Runtime-specific access requirements, consult the AgentCore Runtime permissions documentation.

Cross-account setups need special care. The account that runs the resource, the account that receives telemetry, and the account selected in your CloudWatch view may not be the same. Don’t infer that the data is missing from a single account’s console until you have verified the configured destination and the scope of the query.

Verify self-managed agents with a controlled comparison

An agent that runs outside AgentCore Runtime does not automatically gain Runtime-managed instrumentation just because it uses AgentCore services. You are responsible for checking whether the application creates spans and exports them. Inspect the OpenTelemetry SDK initialization, any framework instrumentation, exporter configuration, and telemetry-related environment variables in the actual process that handles requests. A setting present in a developer shell may not be present in a container, service definition, or production task.

Use the same small, identifiable request for a local-and-cloud comparison:

• Run a request locally and confirm that the application creates the expected spans.
• Record the instrumentation and exporter settings used by that process, without recording secrets.
• Run the same kind of request in the cloud and inspect the deployed process configuration rather than relying on your local environment.
• Compare the destination, credentials or permissions, and network path used by the deployed process.
• Search for the cloud request in the correct account, Region, time range, and trace view.

If the spans exist locally but not in the cloud, focus on differences in deployment configuration and delivery. If neither environment produces spans, investigate instrumentation before changing CloudWatch search settings. Keep application logs and spans distinct: one may be generated and exported while the other is not.

This comparison narrows the cause without turning the investigation into a full deployment tutorial. If you still need a broader production setup, use the kvmboot help center to find the relevant support route, and retain a minimal reproduction rather than sharing a full production payload.

Apply a conditional decision path

Choose the next action from what you have verified:

• If the account, Region, resource, or time window is wrong, correct the query scope first; do not change telemetry or permissions yet.
• If Transaction Search is not enabled for the scope you are searching, follow the current CloudWatch enablement steps, then test with a new request.
• If the resource is not configured to emit the missing signal, update that resource’s telemetry configuration and verify its documented destination.
• If the resource is configured but data does not arrive, compare the destination and required delivery permissions, then inspect relevant service or application errors.
• If the agent runs outside AgentCore Runtime and no spans are created, correct or add OpenTelemetry instrumentation before diagnosing CloudWatch ingestion.
• If configuration and delivery checks pass but the trace is still absent, preserve the reproduction details and use the current Runtime troubleshooting guidance instead of repeatedly changing unrelated settings.

This sequence also answers a common operations question: don’t start with IAM for every missing trace, and don’t start by changing the destination for every empty log view. First establish the expected signal, its source, and the query scope. Then use the symptom to decide whether configuration, access, or search is the remaining uncertainty.

Preserve evidence without exposing request data

A useful incident note lets another engineer repeat the check without needing access to sensitive prompts, customer records, or credentials. Record the resource type and identifier, account and Region, approximate request time, invocation outcome, expected signal, telemetry settings reviewed, configured destination, and the query view used. Include the checks already completed and the result of a controlled follow-up request.

Avoid copying full request or response payloads into tickets by default. Prompts and tool results can contain personal, confidential, or credential-like information. Prefer a correlation identifier or a redacted minimal example, and follow your organization’s retention and access policies before enabling payload logging. The fact that more detail could help a diagnosis does not make unrestricted payload capture a safe default.

A compact reproduction record can look like this:

Resource type and identifier:
Account and Region:
Request time and correlation reference:
Invocation outcome:
Missing signal: logs / traces / metrics
Transaction Search status:
Resource telemetry configuration checked:
Configured destination:
Permissions or delivery errors checked:
Query view and time range:
Local-versus-cloud comparison, if applicable:
Sensitive fields removed:
Next verification:

Scenario: A Runtime request returns an application error, while CloudWatch shows metrics but no spans. First confirm the request belongs to the selected Runtime and query window. Then check whether the relevant Runtime trace telemetry is configured, whether Transaction Search is enabled in the queried scope, and whether the documented Runtime spans view is being used. Only after those checks should you investigate destination permissions. This keeps an application failure, a telemetry configuration gap, and a search-scope mistake from being treated as the same incident.

Choose the right environment for the next test

AWS remains the relevant environment for validating AgentCore Runtime behavior, CloudWatch delivery, and account-level settings. A rented Mac cannot repair a missing AWS permission or make a cloud trace appear. It can, however, provide a temporary local environment for reproducing an agent issue, comparing an OpenTelemetry setup, or testing client-side tooling without changing a developer’s primary machine.

That distinction matters when deciding whether to rent or keep troubleshooting locally. Continuing only in the existing cloud setup can mean repeated deployments, noisy production tests, and limited isolation between application and infrastructure changes. A separate Mac test environment can offer a clean local comparison, but it adds a separate environment to manage and does not replace AWS for validating managed Runtime telemetry. If you need a temporary Mac for that isolated reproduction, review the available kvmboot Mac environment options; if the issue is a long-running production workload or depends on physical hardware you do not have, renting may not fit.

Once you have separated missing logs from missing traces, record the verified configuration and keep the reproduction small. For Amazon Bedrock AgentCore trace troubleshooting, the most reliable next step is the one tied to the observed gap: correct the query scope, enable the required search and resource telemetry, verify the destination and permissions, or instrument the self-managed agent.