If a user who should have received a message hasn’t, there could be a few reasons why. This troubleshooting guide will help you get to the heart of the problem.
Note: resolving delivery issues that involve calling Intercom JavaScript API methods (such as Intercom('shutdown')) requires access to your app's codebase so involve your development team if needed.
First, understand how each message gets delivered
We send one-off messages immediately (unless you’ve scheduled one). This means that we’ll look for all the users who match your filters, and we’ll send it as soon as we find them.
For ongoing messages, we check once per hour to see who has become eligible to receive your messages.
For series, Whenever a customer logs in to your app, or visits your website, and is tracked by Intercom, they’ll enter any series where they match the entry rules for a path.
If they haven’t logged in, entry rules are checked once an hour for anyone who should enter. Rule blocks in the middle of a path (when the customer has already entered the series) are checked approximately every 15 minutes.
For in-app messages (chats, posts etc), we only deliver when a user is online to receive them. We will only match and send in-app messages when users “ping”, i.e: when they are online and your app is sending us updates about them. The 'Last seen' value tells you when the user was last available on your site to receive a message. If your mobile app uses the web-based Messenger (rather than the native iOS or Android SDK), it only generates web pings — not iOS or Android pings. This means setting "Show first on" to iOS only will never match, and in-app messages won't appear. Include Web in the "Show first on" setting so messages can match the web-based Messenger running inside your mobile app.
Messages which have a push notification attached to them will send immediately.
Is the user's Messenger session still active?
For in-app messages, delivery is controlled by the Messenger session, not the user's login status in the host app. When a user is identified via Intercom('boot') with a valid JWT, a session cookie is created with a default duration of 7 days. This session persists even after the user logs out of your app — until you explicitly call Intercom('shutdown').
This means a user who has logged out of your app can still receive in-app messages the next time the Messenger loads, if their session cookie hasn't expired.
Important: Audience conditions are checked each time the Messenger loads, not at logout. So exclusion filters will work, but only if the Messenger actually boots while the session is active.
To prevent delivery to users who have logged out or been excluded:
Call
Intercom('shutdown')inside your logout event handler. This clears the session cookie immediately and starts a fresh anonymous session for the next visitor on that device.Include any exclusion status in the message's audience filter (e.g.
excluded_user is not true). Conditions are re-evaluated on each Messenger load, so this prevents delivery even if a session is still technically active.Optionally, reduce the max session duration under Settings > Channels > Messenger > Keep your Messenger secure to match your app's own session length.
Note: This behavior applies to identified users only. Anonymous visitors use a separate cookie-based session unaffected by JWT-based session persistence.
Is Messenger Security blocking delivery to signed-in users?
When Messenger Security is enabled on your workspace, chat messages to signed-in users are only delivered if a valid security token is provided during the Messenger boot call. If the token is missing or invalid, the Messenger does not complete a secure boot on that page — so no ping is sent, the user's Recent page views stay empty, and in-app chat messages cannot be delivered, even if the user is actively on the page.
How to check: On Settings > Channels > Messenger > Security, review which of your production domains are passing the security check. A domain showing as "not ready" means pings from that domain aren't carrying a valid token, and the signed-in Messenger on it won't complete a secure boot. Confirm with your developers that a fresh JWT (or Identity Verification hash, if you're using the older method) is being generated server-side and passed into the Messenger boot call for that exact domain. See Authenticating users in the Messenger with JSON web tokens (JWTs) for setup steps.
This security check only applies to the signed-in install, where the Messenger boots with a known identity (user_id/email). Leads reached through an anonymous marketing-site install are not subject to this check and can receive in-app chat messages as long as the Messenger is loaded on their page — the same session-based delivery rule described above, with no token required.
Next, answer these questions
If you still haven't figured out why your message isn't sending, you'll need to answer the following questions:
Are you sending the message to a large audience?
Messages with a large audience might take some time for us to process. When you set a message live, we check all the message filters and see which of your users match them. The larger the message, the longer this processing can take to complete.
Do users match the filters you’ve set?
In Intercom, all messaging is trigger based. In other words, recipients have to match the filters you’ve set on a message before they become eligible to receive it. Examples of filters would be “Signed up less than 30 days ago” and “Plan is lite’
When you add filters to a message, these become the criteria that Intercom uses to check a users’ eligibility for the message. For example, if you have a message set up with the filters above, it would look like this:
Currently no users match these filters, so no-one will receive the message. However, as it’s an ongoing message, Intercom will check every hour to see who matches these filters and it will send the message to any users who do.
If users match this message’s filters, they will show on the right hand-side of the window. Here’s how the message looks when people match the filters:
Has that user unsubscribed?
If a user has unsubscribed from email messages from your app, they won’t receive any more bulk emails from you. They can still receive in-app messages and email messages sent only to them, however they won’t receive any manual and automatic email messages.
Has the message bounced?
If Intercom tries to send a message to a recipient and there is a permanent failure, also known as a hard bounce, we won’t attempt email deliveries to that recipient again. This is because it’s dangerous to continually attempt delivery to hard bounced addresses and it can harm your sending reputation and ability to get messages to the email inbox.
Has that user marked the message as spam?
Equally, if a recipient marks one of your emails as spam, you won’t be able to send them any more emails from your Intercom app.
Users who are unsubscribed, bounced or who have marked your messages as spam will automatically be removed from the audience of bulk messages. If you try to send a message to someone who has previously bounced or complained, Intercom won’t attempt delivery.
Certain addresses are not meant to receive marketing email, and are automatically deemed ineligible to receive email. Examples include abuse@ and postmaster@ addresses.
If you try to send a message and all the recipients are ineligible to receive it, you might see a message which says: “we’re preparing this email and it’ll start sending shortly."
Note: If a user or lead's "marked as spam" attribute is 'true' but you have gotten written or verbal consent from them to receive emails from you again, reach out to our support team who can help update the user for you. It's important that you gain consent from the user/lead first, since emailing people who continue to mark your emails as spam can harm your sender reputation and increase the likelihood of your emails being routed to customers' spam filters.
Have you scheduled your message to send inside a delivery window?
If you’ve scheduled your messages to send at a certain time or inside a delivery window, that might delay delivery. For example, you might want to set a message live at 9am in another timezone while you’re fast asleep - you can schedule a message to do this.
You can also set up delivery windows, which might affect delivery times for messages. If you have a message with a delivery window of 9am to 5pm, it will deliver when it falls within that time window in the recipient’s time zone. If we don’t know the recipient’s time zone, we will fall back to the timezone of the app.
Note: Messages with delivery windows send according to the recipient’s timezone, not the sender’s timezone, unless there is no location data available for the recipient, in which case we fallback to using the app’s timezone.
Need more help? Get support from our Community Forum
Find answers and get help from Intercom Support and Community Experts