Skip to main content
If you need to troubleshoot your integrations with Honeycomb, explore these solutions to common issues.
To ask questions and learn more, visit our Support Knowledge Base or join our Pollinators Community.

​
AWS DevOps Agent

Troubleshoot issues related to 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.
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.

​
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.
title and description must pass through toJson and stay unwrapped by quotation marks.

​
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.

​
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.