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

# Common Issues with Integrations

> Troubleshoot common problems with Honeycomb integrations, including AWS, Terraform, webhook delivery, and third-party tool connectivity issues

If you need to troubleshoot your integrations with Honeycomb, explore these solutions to common issues.

<Tip>
  To ask questions and learn more, visit our [Support Knowledge Base](https://support.honeycomb.io/) or [join our Pollinators Community](/troubleshoot/community/).
</Tip>

## AWS DevOps Agent

Troubleshoot issues related to [AWS DevOps Agent](/integrations/aws-devops-agent).

### Telemetry introspection

Most connection problems trace back to how the API key was entered during registration, not the key itself.

#### "Invalid input" error when saving the authorization configuration

This happens when the full header string, rather than just the header name, was entered in the **API Key Header** field.
Enter `Authorization` alone in that field, and move the rest of the value to **API Key Value**.

#### Registration saves, but the agent reports it can't reach Honeycomb

The **API Key Value** is malformed.
Confirm the value is `Bearer <KEY_ID>:<KEY_SECRET>`: both halves present, joined by a colon, with a single space after `Bearer` and no wrapping quotation marks or whitespace.

#### Agent authenticates, but reports no environments

The key is missing the **Environments (Read)** scope, or it belongs to a different Honeycomb team than expected.
Check the key's scopes in Honeycomb, and confirm which team issued it.

#### Agent lists environments, but returns no data for a service

The service isn't sending traces to the environment the key can see, or the query window predates the data.
Confirm in the Honeycomb UI that the dataset holds spans for the time range in question.

#### Requests fail from an EU-hosted team

The registration used the US endpoint instead of the EU one.
Re-register using `https://mcp.eu1.honeycomb.io/mcp`.

To rotate the credential:

1. Create a new Management API key in Honeycomb.
2. Edit the registration's authorization configuration with the new value.
3. Verify with the same prompt used during setup.
4. Delete the old key in Honeycomb.

### Trigger investigations

Most delivery problems either get an explicit rejection, like a `403`, or fail silently with no error at all, so check the response code before assuming the payload itself is wrong.

#### Honeycomb reports "403 Forbidden" on every delivery

The `Authorization` header sent with the webhook doesn't match what AWS DevOps Agent expects.
Delete the header on the **Headers** tab and re-enter it as `Bearer <API_KEY>`.

#### "403 Forbidden" persists after you re-enter the header

The webhook credentials were removed or regenerated on the AWS DevOps Agent side, or the endpoint URL doesn't match the webhook that was generated.
Regenerate the credentials in the **Webhook** section of the **Capabilities** tab, then update both the URL and the header in Honeycomb.

<Note>
  Honeycomb doesn't retry `403` responses, so correcting the header only takes effect on the next delivery.
  Use **Test** in the Trigger editor to confirm the fix instead of waiting for a real alert to fire.
</Note>

#### A `200` response comes back, but no investigation starts

Honeycomb delivered the payload successfully, but AWS DevOps Agent rejected it during validation.
This usually means the `priority` value isn't one of the five literal strings (`CRITICAL`, `HIGH`, `MEDIUM`, `LOW`, `MINIMAL`), or a free-text field like `title` or `description` was interpolated into a quoted string instead of passed through `toJson`, producing invalid JSON.
Confirm the `priority` value on the **Payload** tab matches one of the five literal strings, and check any free-text field for missing `toJson` wrapping.

<Warning>
  `title` and `description` must pass through `toJson` and stay unwrapped by quotation marks.
</Warning>

#### Deliveries fail intermittently with no clear pattern

Honeycomb expects a response within 15 seconds and retries a delivery only for a `408`, `502`, a `429` or `503` carrying a `Retry-After` header, or a connection-level failure such as a refused connection.
If AWS DevOps Agent is slow to acknowledge the request, or returns any other status while under load, the delivery fails without a retry.
Make sure the webhook endpoint acknowledges the request quickly and handles any slower work asynchronously.

#### A repeated alert doesn't start a new investigation

Deliveries within the same alert cycle carry the same `incidentId`, so AWS DevOps Agent treats them as updates to the existing investigation instead of starting a new one.
This is expected behavior; a new investigation starts when the Trigger recovers and fires again.

#### The webhook integration doesn't appear as an option on an SLO burn alert

Only the **Triggers** payload type is enabled on the integration, and a webhook can only be used with alert types whose payload is configured.
Enable the **Budget Rate Burn** or **Exhaustion Time Burn** payload on the **Payload** tab.

To rotate the webhook API key, remove the existing credentials in the **Webhook** section of the **Capabilities** tab, generate new ones, and update the `Authorization` header in Honeycomb.
Requests succeed again once the new header is saved.

#### An investigation starts, then gets cancelled immediately

This usually means your AWS account has hit its monthly investigation limit.
Contact your AWS account team to request a rate limit change.

## PagerDuty

Troubleshoot issues related to [PagerDuty](/notify/pagerduty/).

### You do not receive alerts from PagerDuty when a trigger fires

If there are gaps in your escalation policy schedule, PagerDuty will not create an incident if no responder is on-call during the moment the trigger fires.

Examine your PagerDuty escalation policy to ensure that a responder is always on-call in PagerDuty.