Workflow emails can get stuck in the queue, show incomplete analytics, or behave unexpectedly with reply-to addresses and branching logic. This guide covers the most common issues and how to resolve them.

Quick checks

• Open the Workflow in Analytics view and click the Email node to see its current metrics (In Queue, Sent, Delivered, Bounced, Skipped).
• If you have a lot of published Emails, you could be reaching your Email Rate Limits. Appcues Support can confirm if your account has hit its hourly or daily sending cap.
• Confirm the user property that holds email addresses is being passed correctly. Users without a valid email property won't receive emails.

Emails stuck “In Queue”

Users appear in the In Queue count on the Email node but emails aren't being sent.

Cause 1: Rate limit reached

Appcues limits how many emails your account sends per hour and per day. New accounts start at 450/day and 113/hour. When you hit the limit, additional emails are queued until capacity frees up. If you have multiple Workflows with Email nodes, all of them share the same rate limits. A high-volume Workflow can consume capacity that delays emails in other Workflows.

Fix:

• If you're consistently hitting your limits with a custom domain or Appcues subdomain, email support@appcues.com with your domain's normal daily send volume to request an increase.
• On occasion, consider staggering Workflow launches or reducing audience size.
• Queued emails will send automatically once capacity is available — no manual intervention is needed.

Note: The queue reason shown in Studio may display “Outside sending window” even when the actual cause is a rate limit. This is a known labeling issue.

Cause 2: Sending window restrictions

If the Email node has a sending window configured (for example, weekdays 9 AM–5 PM), emails are only sent during that window based on the user's timezone.

How to check:

1. Open the Email node in the Workflow builder.
2. Check the When can this email be sent? settings for any day/time restrictions.
3. Confirm that Appcues has timezone data for queued users. If the user's timezone isn't set, Appcues may not evaluate the sending window correctly.

Fix:

• If the sending window is intentional, wait for the next window to open.
• To send immediately regardless of time, change the sending behavior to At all times.

Cause 3: Waiting for another email to be sent first

The queue reason “Waiting for another email to be sent first” means this email is behind another pending email for the same recipient. Appcues won’t attempt to send this message until the earlier email request(s) for that user have been processed (sent or skipped).

This can happen when:

The user becomes eligible for multiple emails close together (either within the same Workflow or across multiple Workflows), creating a per-user backlog.
Earlier emails for that same user are still queued due to sending constraints elsewhere (for example, overall account throughput/rate limiting), so subsequent emails remain blocked behind them.

Fix:

• In most cases, this resolves automatically once the earlier pending email(s) are processed.
• If users remain stuck for an extended period, contact Support and include: the Workflow URL, the Email ID (if available), and example user ID(s) so we can look for what’s ahead of them in the queue and what’s preventing progress.

Users exit the Workflow before reaching an Email node

Users enter the Workflow but never reach the second (or third) Email node.

Cause: Segment-based exit criteria conflict with time delays

If your Workflow's entrance segment has a time-based condition (for example, “First seen at less than 7 days ago”), users can fall out of the segment while waiting in a Time Delay node. Users must remain in the entrance segment to stay in the Workflow. If they no longer qualify, they exit.

Example: A Workflow sends Email 1, then waits 7 days, then sends Email 2. If the entrance segment requires “First seen at less than 7 days ago,” users will exit the segment during the delay and never receive Email 2.

Fix:

1. Review your entrance segment's time-based conditions.
2. Ensure the time window is long enough to cover the full Workflow duration, including all delays.
3. Alternatively, restructure the segment to use a condition that won't expire before the Workflow finishes (for example, “First seen at less than 30 days ago” for a Workflow that spans 21 days).

Users exit the Workflow before receiving an Email

Users move past the Email node — and potentially out of the Workflow — before the email is sent or delivered.

Cause: Node progression set to "Immediately"

When When can users move to the next node? is set to Immediately, the user advances without waiting for the email to be sent, delivered, or opened. If the next node is a branch or exit condition, the user may leave the Workflow before the email reaches their inbox.

Fix:

1. Select the Email node on the canvas and find When can users move to the next node? in the settings panel.
2. Change Immediately to Sent or skipped (safest default), Delivered, or Opened — depending on how critical the email is to the next step.
3. Set a Maximum wait time so users aren't stuck if the email bounces or is never opened.
4. Republish the Workflow.

Workflow branch conditions not filtering users correctly

Users aren't routed to the expected True/False branch based on a date or time property.

Cause: Using numeric comparison instead of date conditions

Workflow branch conditions for user properties don't support date comparisons directly. If you try to compare a timestamp property using “greater than 60” to mean “more than 60 days ago,” it won't work — it compares the raw value as a number, not as a relative date.

Fix:

1. Create separate user segments for each time-based condition (for example, “Last login more than 7 days ago,” “Last login more than 30 days ago”).
2. In the Workflow, use a True/False Branch that checks segment membership instead of comparing the property value directly.
3. For multi-tier branching (7 days, 21 days, 30 days, 60 days), create a segment for each tier and chain branches that check membership in each segment.

Emails bouncing or being skipped

Bounced emails

An email can soft-bounce and be retried for up to 8 hours before being marked as bounced. Common causes:

• Recipient's mailbox is full.
• Recipient's email server is temporarily unavailable.
• The email address is invalid or doesn't exist.

If a recipient hard-bounces, they're automatically added to the Bounced suppression list. Future emails to that address will be skipped.

Skipped emails

Emails are skipped (not attempted) when:

• The recipient is on a suppression list (Bounced, Complained, or Unsubscribed).
• The email address is invalid or flagged as high-risk.
• The user doesn't have an email property set.

Fix:

1. Go to Settings > Emails > Suppression Lists to check whether the user's address is on a list.
2. If a user was added to the Bounced list in error (for example, their mailbox issue was temporary), you can remove them from the suppression list to re-enable delivery.

Reply-to address not working as expected

Automatic responses (like out-of-office messages) are going to the sender address instead of the reply-to address you configured.

Cause: Auto-replies ignore the Reply-To header

This is standard email behavior, not an Appcues quirk. Most email servers send auto-generated replies (out-of-office, delivery receipts, read receipts) to the From address in the email header, not the Reply-To address. Only manual replies from the recipient respect the Reply-To field.

What to expect:

• Manual replies from recipients go to your reply-to address.
• Auto-replies (out-of-office, delivery failures) go to your sender (From) address.

Fix:

• If auto-replies to the sender are disruptive, set up an inbox filter on the sender's email to auto-archive or redirect them.
• This cannot be changed in Appcues — it's determined by the recipient's email server.

If it's still not working

Collect the following before contacting support@appcues.com:

• Workflow URL — open the Workflow in Studio and copy the browser URL.
• Email node name or ID — visible in the Email node's settings panel.
• Example user ID — a specific user experiencing the issue, found in the Users list.
• Date range — when the issue started and what date range you're viewing in Analytics.
• Screenshot — of the Email node analytics or the queue status.
• Queue reason (if applicable) — the reason shown for queued emails (for example, “Outside sending window” or “Waiting for another email”).