What to check from the dashboard#
Automations that "don't fire" almost always have a UI-visible reason — wrong status, wrong trigger, or the subscriber doesn't match the condition the workflow is waiting for. Walk these three checks before logging into the server.
Open Automations in the left sidebar:
Find your workflow row. Three columns matter:
- Status —
Active means it will trigger; Inactive, Draft, or Paused will NOT.
- Last run — when did a subscriber last enter this workflow?
- Subscribers in flow — current count of recipients somewhere in the steps.
If status is anything but Active, that's your fix. Click the row → Settings → toggle Active. Save.
Check the trigger node#
If status is Active but new subscribers still aren't entering, click the workflow name to open the flow canvas:
The first node is the trigger. Common misconfigurations:
| Trigger type |
What it listens for |
Common pitfall |
| Subscribed to list |
New rows in a specific mailing list |
Wrong list selected — workflow fires on List A but subscribers are being added to List B |
| Tag added |
A specific tag attached to a subscriber |
Tag name typo / case mismatch — vip vs VIP are different |
| Custom event (API) |
Your application calls POST /api/automations/{uid}/event |
API call missing or hitting wrong workflow uid |
| Date relative |
A specific date field (birthday, signup_date) matches today |
Field empty for most subscribers — workflow only fires for the few with that field populated |
| Link clicked |
Subscriber clicks a specific link in a campaign |
Link not yet clicked by anyone — wait for engagement |
Hover over the trigger node — the right-hand panel shows the exact configuration. Verify it matches your list, tag, or event name.
Verify the workflow settings#
Click Settings in the top-right of the flow canvas:
Three settings commonly block firing:
- Allow re-entry? — If OFF, a subscriber who entered once (even years ago) can't re-enter. Toggle ON if you want every signup to flow through.
- Cooldown period — A subscriber who entered N hours/days ago can't re-enter until cooldown expires.
- Eligibility filter — Optional segment/tag filter. Subscribers who don't match the filter skip the workflow entirely.
Common UI causes and the fix from the dashboard#
| What you see |
Likely cause |
What to do |
| Status: Inactive |
Workflow toggled off (common after edits — AcelleMail un-activates on save). |
Open Settings → toggle Active → Save. |
| Trigger = Subscribed to list, wrong list |
Workflow listens on List A but new signups go to List B. |
Edit trigger → pick correct list → Save. |
| Trigger = Tag added, no recent tagging |
Tag never added to any subscriber. |
Either tag a subscriber to test, or change the trigger to a more reachable condition. |
| Trigger = Date relative, empty fields |
Most subscribers don't have the date field populated. |
Import the field via CSV update, or change to a different trigger. |
Status: Active but Subscribers in flow = 0 |
Trigger fires correctly but the first delay node hasn't elapsed yet. |
Wait for the delay duration, then refresh. |
| Status: Active, Subscribers in flow > 0, no emails sent |
Send-step is failing (sending server issue). |
Check Settings → Sending servers → run Test connection. See Campaign stuck in Sending. |
Test the workflow by hand#
The fastest way to confirm "is this workflow actually firing?" is to manually trigger it:
- Create a test subscriber with an address you control (your own email).
- Add that subscriber to the list / apply the tag / fire the API event — whatever the trigger expects.
- Wait the configured delay (start with workflows that have <5 min first-step delay for fast iteration).
- Check your inbox.
If the test subscriber receives the email → workflow is fine, your original signups aren't matching the trigger (back to dashboard checks).
If the test subscriber does NOT receive → either the workflow isn't firing, or the send is failing. See operator section.
Advanced: server-side checks for the operator
AcelleMail automations run on the same queue worker that processes campaigns. If campaigns are sending but automations aren't, the worker is processing the wrong queue mix.
Queue priorities — automation jobs go onto the automation queue by default. Verify the worker is listening to it:
ps aux | grep "queue:work" | grep -v grep
# Expected: includes --queue=high,default,low,automation
If automation is missing from the worker's --queue flag, restart Supervisor with the correct config:
sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl restart acelle-queue-worker:*
Cron and the master scheduler — acelle:run ticks every minute and picks up time-based automation triggers (date-relative, delayed step transitions). If cron is broken, time-driven steps stall while immediate triggers (subscribe / tag / API event) still work.
crontab -l | grep acelle:run
# Expected: * * * * * php /path/to/artisan acelle:run >/dev/null 2>&1
Inspect a specific automation's history via the database — every entry/exit is logged:
# Recent automation runs
php artisan tinker --execute='
\App\Model\AutomationCustomerInteraction::orderByDesc("id")
->limit(20)->get()
->each(fn($r) => print("uid={$r->automation_uid} sub={$r->subscriber_uid} step={$r->step_uid} at={$r->created_at}\n"));
'
Failed-job inspection — if a step throws an exception, the job goes to failed_jobs. Look for entries with Automation in the payload:
php artisan queue:failed
php artisan queue:retry all # retry every failed job
Workflow-uid → log mapping — to find why a SPECIFIC subscriber didn't enter:
grep "subscriber_uid=<uid>" storage/logs/laravel.log | tail -20
Related articles#
