Tips & Best Practices

Always Test Before You Depend On It

Run every new event manually a few times before it goes into production. Check the Results Log. Make sure output files end up where you expect, named the way you expect. A few minutes now saves a lot of stress at 3am.

Use the Info Tab

Write down what the event does, where content comes from, who to contact at the provider, anything useful. The notes cost nothing and are worth a lot six months from now.

Name Your Events Clearly

"New Download 7" tells you nothing. "AP Radio News - 5am" tells you everything. Name events so anyone glancing at the list understands exactly what each one does.

Chain Events Instead of Stuffing Everything Into One

A fetch event and a processing event chained with "Runs After" are easier to troubleshoot than one monolithic event with ten steps.

Set Up Notifications for Critical Events

For events you absolutely depend on, add a Notify step at the end confirming success. If you don't get the notification, you know something went wrong before your air shift finds out.

Keep Fetchit! Running

Fetchit! must be open for scheduled events to fire. Set it to open at login. Think of it as infrastructure — always running.

Use Disable, Not Delete

If an event is temporarily out of service, disable it rather than deleting it. Re-enable in one click when it's needed again.