Appearance
Run History and Troubleshooting
Every time an automation runs, show.fm records what happened. The Execution History page is where you check that runs went out, see exactly what each step did, and work out why something didn't.
To get there, go to Automations in your podcast's sidebar and click History. Use Refresh to pull in the latest runs.
Filter the list
Two funnels narrow the table:
- Status: All, Completed, Failed, Pending, Processing, or Skipped
- Automation: All Automations, or one specific automation
The table shows 50 runs per page, with Previous and Next below it.
Read the table
| Column | What it shows |
|---|---|
| Status | The run's outcome (see below) |
| Automation | Which automation ran |
| Trigger | The event that started it, like Booking Confirmed |
| Started At | When the run began |
| Duration | How long it took |
| Actions | A Details button for the full breakdown |
What each status means
- Pending: created but not yet running
- Processing: running right now
- Completed: every step finished
- Failed: something went wrong. Open Details to see the error
- Skipped: the run didn't execute because a monthly plan allowance was already used up
Open the Details dialog
Click Details on any run to open Execution Details:
- Status and trigger at the top
- Started and Completed timestamps
- Error: the error message, when the run failed
- Context Data: the information the run carried, which is what magic tags resolved from
- Action Results: a step-by-step record of what each action did
Branch skips are normal
When a run includes a condition, the steps on the branch that wasn't taken show as skipped in Action Results. That's the condition doing its job, not a problem.
Understand skipped runs
Plans include monthly allowances for the things automations consume: automation runs, email sends, webhook sends, notification deliveries, and AI credits. When one is used up, related work is skipped instead of run:
- If the automation runs allowance is used, the whole run is skipped.
- If a specific allowance like email sends or webhook sends is used, just those actions are skipped and the rest of the run continues.
Skipped runs are never silent. The History table flags them with a "Quota reached" note naming the allowance, and the Details dialog explains which actions were affected, with an Upgrade plan button.
Skipped runs and actions don't retry. Allowances reset on the 1st of each month, or you can upgrade to raise them. See Plan Limits.
Check a warning after publishing
Publishing or scheduling an episode starts any enabled automation with the matching trigger. This includes Thank your guest when the episode publishes when you publish manually or confirm that an externally hosted episode is live.
If the Publish page says Check your automations, your episode was saved, but one or more automations could not be started. The warning can also appear as a notification when publishing changes the episode's address.
- Go to Automations → History and select Refresh.
- Check for runs at the time you published or scheduled the episode. Some automations may have started while others failed.
- Contact support with the podcast, episode and approximate time before retrying. A missing run may have failed before it could appear in History; a pending run after a warning may need support to start. Republishing to retry can send duplicate messages.
Troubleshoot a failed run
- Filter Status to Failed and open Details on the run
- Read Error for the headline, and Action Results to see which step broke
- Check Context Data if magic tags came out empty: the tag's record (guest, booking, or episode) may not have been part of that run
- Fix the step in the flow builder, for example a mistyped webhook URL or a send-email step with no template selected
- Check whether earlier steps already sent emails or webhooks before using Test again. A new test starts a new run and can repeat those deliveries.
If an automation isn't running at all, check its switch on the Automations page first: disabled automations never run.
Check recipients and interrupted runs
A guest-email step needs an eligible guest or booking attendee. When Test can establish that the selected context has no guest, it stops before starting the run. Select an episode with a guest, choose a booking with attendees, or change Send to. Recipients are checked again when the email step runs, because guests may have been removed meanwhile.
Podcast hosts sends one email to each current owner of the podcast, using their account email. It does not use the public email address in your podcast feed. Multiple owners are supported. If no owner email can be found, check the team membership before testing again.
With Test Mode on, action results say simulated: true. No email, webhook or record update is performed, and delays are simulated immediately. A completed simulation does not prove delivery; use Test Mode off with recipients you control to check that.
An interrupted run may say that a delivery outcome is unknown. This means an email or webhook might already have reached its destination. Completed steps remain in Action Results, and the interrupted action is not replayed automatically.
- Open Details and read the completed and uncertain actions.
- Check the destination or contact support with the run's details.
- Only start another run after confirming which deliveries would be repeated.
What's Next?
- Adjust your automations in the flow builder
- Check your plan's allowances
- Review your templates if emails aren't reading right