Bot Finder troubleshooting

Events not arriving in InboxEagle

If the Bot Finder dashboard shows no or very low activity, or SQS health is healthy but “Last message” is old or missing:

Check SES Configuration Set — Verify the configuration set ie-config-{ExternalId} is applied to your sending identity or set as the account default. See Apply the configuration set to your sending identity in the setup guide.
Check SNS subscription — In the AWS SNS console, confirm the ie-sns-read-{ExternalId} topic has an SQS subscription with status Confirmed.
Check SQS queue — Send a test email and check the ie-sqs-{ExternalId} queue for messages in the SQS console. If messages appear in SQS but not in the app, the ingest worker or tenant configuration may need to be verified (see operator docs).
Check event types — The configuration set routes all SES event types (open, click, delivery, bounce, complaint) automatically; no manual event type selection is needed.

Verify you ran the put-email-identity-configuration-set-attributes (or account-level default) command from the setup guide.
The configuration set name is ie-config-{ExternalId} and is shown in the CloudFormation Outputs tab.
Send a test email and confirm messages appear in the ie-sqs-{ExternalId} queue.

If the app shows that Bot Finder is still provisioning or the connection never becomes active:

Verify the Role ARN format matches: arn:aws:iam::{accountId}:role/inboxeagle-role-{externalId}-{region}.
Confirm the ExternalId in the CloudFormation stack matches what was used when creating the stack (and that it is consistent with what the backend expects).
Check that the IAM role trust policy allows the InboxEagle AWS account to assume the role (e.g. account 051826705850 if that is your deployment’s account). If you use a different trust account, ensure it is correct.

Disconnected — No configuration is saved, or Bot Finder was disconnected. Go through the Bot Finder setup again and complete all steps (ARN validation, select SES config set, save configuration).
Unreachable SQS — The pipeline cannot reach your SQS queue. Common causes:
- Permissions — The IAM role that InboxEagle assumes must have permission to receive messages from the queue (and to access the SNS topic that feeds it).
- Region / queue URL — Ensure the queue URL and region match the role and stack (e.g. same region as your SES configuration set).
- Backend health — If the Lens ingest worker or app backend is down or misconfigured, status may show unreachable. Check activity log for errors and contact support if the queue is correct and permissions are in place.

If you deliver Bot Finder results to a webhook and events are not reaching your endpoint:

HTTPS required — Webhook URLs must use https:// in production; http:// is rejected.
Timeout — Your endpoint must respond within the configured timeout (default: 5 seconds). Slow responses can cause retries or failures.
Status codes — Return 2xx for success. 5xx and 429 are retried with exponential backoff; other 4xx responses are treated as permanent failures and are not retried.
Dead letters — After 10 failed delivery attempts, events are dead-lettered and stop retrying. Fix the endpoint or configuration and reprocess if your system supports it.

If you added a honeypot link but clicks are not being classified as honeypot:

Verify the link URL contains ?_ie=hp or &_ie=hp as a query parameter. No other parameter name is used for this feature.
The link must point to a real, trackable URL — SES must record the click event for InboxEagle to receive and analyze it.
Confirm open and click tracking is enabled on your SES configuration set.
Check that the trap_detection rule category is not disabled for your tenant (operator/backend setting).