Templater’s documentation tells you exactly how a row moves through the Bot and how a failed row is marked. It does not tell you what the Bot does with the rows behind a failed one. If you are about to leave a 500-row batch running overnight, that gap is the thing to plan around, and this article is about planning around it honestly.
We will separate three kinds of statements here. The first kind is what our support documentation states outright. The second is what you can see for yourself in the render-status column and the log files. The third is what the documentation is silent about, which we will mark clearly and give you a short test for, because a guess about a render queue is an expensive thing to learn at six in the morning.
What the documentation says happens to every row
The Bot works from a data source with a column named render-status. You, or the application that feeds your sheet, put the word ready in that column for each row you want rendered. Everything else that ever appears in that column is written by Templater. The documentation is firm about this. The only values you should enter yourself are ready, or an empty cell.
When the Bot checks the data source, it retrieves every row marked ready. It then changes the render-status of all of those retrieved rows to queued. So if your sheet has 500 rows marked ready and the Bot picks them all up in one check, all 500 show queued almost at once. Queued means “accepted, waiting for its turn.” It does not mean “rendering.”
Then the Bot takes the queued rows one at a time. For each row it sets render-status to processing, versions the target composition with that row’s data, writes the output, and sets render-status to done. The documentation also states the other path in the same breath. If the Bot hits errors while processing a row, it sets that row’s render-status to a code such as ERR::MEDIA or ERR::AFXHOST instead of done.
After all the rows it retrieved are finished, the Bot keeps checking the data source for new ready rows. It does not stop when the batch ends. It goes back to waiting, which is the whole point of the Bot, and it is also why a batch that failed halfway can look the same as a batch that is simply idle if you only glance at the machine.
That is the full documented lifecycle. Four ordinary values, ready then queued then processing then done, and error codes in the place where done would have been. Notice what the lifecycle gives you. At any moment the column is a map of the batch. A row that says done has finished. A row that says processing is the one being worked on right now. A row that says queued has not been touched. A row with an error code has failed, and the code says roughly why.
One small detail matters for an overnight run. As of Templater 2.9.5, when the Bot updates the render-status column it overwrites any formulas in those cells with the formula’s result. If you built a clever formula in that column to show something to your team, the Bot will flatten it. Keep your own dashboard logic in a different column.
The two error codes, and what each one actually tells you
The documentation defines two failure values for render-status. They describe very different failures, and they deserve different reactions the next morning.
ERR::MEDIA means Templater ran into an issue locating or importing a media asset. The documentation adds a detail that is easy to skim past and important to act on. In many cases, the output video may have been rendered, but it may contain a media issue within the rendered output. Read that twice. An ERR::MEDIA row is not necessarily a row with no file. It can be a row with a file that has a missing logo, a black frame where a clip should be, or a placeholder where a photo should be. If you treat ERR::MEDIA as “nothing came out” and simply requeue it, you may overwrite a file you could have inspected. If you treat it as “probably fine,” you may ship a broken video. The right reaction is to open the file and look.
Our FAQ describes a related failure from the After Effects side. The render queue item shows the message “Failed at N/A,” which indicates that After Effects did not find one or more assets, footage or font dependencies in their specified location, and the FAQ notes that files may have been inadvertently moved or deleted. That is the same family of problem. Footage that lived on a drive that was unmounted at midnight, or a font that was uninstalled during an update, will look like this.
ERR::AFXHOST is a different animal. The documentation says that Templater’s host application, Adobe After Effects, encountered an error, and that you can learn more by viewing After Effects on the machine running Templater. Then comes the sentence that matters most for an unattended run. When you see this error, After Effects will likely have stopped operating normally.
Put those two codes side by side and the practical difference is plain. ERR::MEDIA points at your data and your files. You fix a path, a filename or a missing asset, and the machine itself is fine. ERR::AFXHOST points at the application on that machine. Fixing the row’s data may not be the fix at all, because the host stopped behaving. You go and look at After Effects.
That second code is also where the documentation goes quiet, so let us be precise about the silence. The documentation says After Effects will likely have stopped operating normally. It does not say what the Bot does next. It does not say whether the rows behind the failed one stay queued, whether they continue, or whether anything is written to them at all. We will not fill that in, because the honest answer from the documentation is that it does not say.
What the documentation does not say, and how to find out on your own machine
Here is the list of things a person running an overnight batch would reasonably want to know, with our documentation’s position on each.
Does a failed row stop the rest of the batch? Not stated. The lifecycle describes what happens “for each queued row” and describes the error code as the outcome for the row that errored. It does not say whether the loop moves on to the next row after an error code is written.
Is a failed row retried automatically? Not stated. None of the pages we have use the word retry. If you read the page on the Bot and the pages on the data source, there is no retry setting described.
What status do the rows after a failure end up with? Not stated. They were set to queued when the Bot retrieved them, and the documentation does not describe them being changed back.
Does the After Job event fire for a row that failed? Not stated either, and the wording of the event is worth a careful read. The documentation says the After Job event is broadcast immediately after Templater completes a single job, and that a job is deemed complete after output is generated. Whether a job that ends in an error counts as complete, for the purpose of that event, is not spelled out. So do not build a notification on the assumption that After Job tells you about failures. Test it.
The test is cheap. Build a small data source, five rows is plenty, using your real project and your real output settings. Make row three fail on purpose in the mildest way available, which is a media path that points at a file that does not exist. That should give you the ERR::MEDIA case, and you can watch what the Bot does to rows four and five while you do it. Write down what render-status shows for every row at the end, whether row three produced a file, and whether a script registered on the After Job event ran for it. A short test like that tells you more about your own setup than any article, including this one, because your version of Templater, your After Effects version and your media are what the Bot actually runs against.
We would not try to force the ERR::AFXHOST case on your production machine to see what happens. Run that experiment on a spare machine or not at all. The documentation says the host will likely have stopped operating normally, and a machine in that state is not a place to learn on a deadline. What you can do instead is design for it, which is the next section.
A note on version. Several of the events we mention depend on the Templater version. The event list in the documentation is described as applying as of version 3.4, and the Post Job, Post Batch and On Bot Disable events are described as broadcast as of version 2.1.10. If you are on an older install, check before relying on any of it.
Building an evidence trail before you go to bed
You cannot make a batch unable to fail. You can make sure that when it does, the morning tells you what happened. Templater gives you three places to collect that evidence, and they are worth setting up before a long run, not after one.
The first is the render-status column itself, which we have been describing. Its great virtue is that it is written per row, by the thing that did the work. When you open the sheet in the morning, count the values. A column that reads done all the way down needs only a spot check of the output files. A column with a block of error codes tells you which rows to open. A column that ends in processing or queued tells you the run did not finish, and the row marked processing is the likeliest candidate for the one the Bot was working on when it stopped.
The second place is the log. Templater can write messages and errors to files. Set the log directory in Templater Preferences, in the Advanced group, because if you leave it empty the log goes to the logged-in user’s documents folder. The files you will care about are templater.log, templater.err and templater.out. The .out file carries color encoding and is meant for watching live. The .log file has the encoding removed and is the one to share or read in a text editor. The .err file collects errors. One warning from the documentation deserves repeating. Reset Log erases the contents of existing log files. If you click it out of habit before an overnight run, you lose whatever the last run left behind. Copy the old logs somewhere first.
The documentation also describes the shape of an error as logged by the command line interface. Each error is a single line with a numeric code, a short description, the message After Effects threw if there was one, a details field with suggestions, and a time stamp. The code table includes an entry for an error swapping a footage source, one for an error downloading a remote footage source, one for a footage file that could not be found on the network, one for an error conforming row data, and one for a layout engine error, among others. The time stamp is the quiet hero here. If your render-status column says row 212 failed and the error file has one line stamped at 2:14 in the morning, you now know when it happened and can line it up with everything else that happened on that machine at 2:14, such as a backup job or a drive going to sleep.
The command line interface also has a setting that matters if you want a failure to be loud. The error code can be listed in a quit_on_errors array in the templater-options.json file, and doing so forces After Effects to quit on the first occurrence of that error. Whether you want that depends on your tolerance. A machine that quits on the first missing asset stops making potentially flawed videos. It also stops making all the good ones that would have followed. That is a real trade-off, and it is yours to make.
The third place is event scripts. Templater broadcasts events at the points we have been discussing, including before and after each job and after the whole batch, and you can register shell scripts or ExtendScripts to run on them. Event scripts require Templater Bot. The documentation lists sending notifications such as an email or text message when a batch of renders completes as one of the things shell scripts are good for. A script on the After Batch event that emails you a summary of the render-status column is a very reasonable first project. Just remember the point above. Test which events actually fire when something fails before you rely on them for failure alerts.
Two more cautions from the documentation about scripts. Shell scripts do not log to a file by default, so if you want a trace of what your script did, redirect its output yourself or use the logging method in Templater’s ExtendScript API, which writes to templater.log and templater.err. And the script file must be executable by the user running After Effects, or it will silently do nothing useful. The troubleshooting page for event scripts suggests searching the log for the phrases EVENT SCRIPT ERROR or EXEC SHELL SCRIPT, and copying the full command line Templater reports so you can run it yourself in a terminal.
The morning after: recovering a batch without making it worse
Suppose you open the sheet at seven and find 412 rows reading done, 9 reading ERR::MEDIA, and the rest still queued or blank. Here is how we would work through it, using only behavior the documentation states.
Start with the log, before you touch the sheet. Copy templater.log and templater.err to a safe place. Find the time stamp of the first error. Everything that happens next in the sheet will be easier to read if you know that moment.
Then look at the ERR::MEDIA rows and open their output files, if they exist. The documentation says the output may exist with a flaw in it. Check each one. For the ones that are flawed, find the asset that was missing or unreadable, fix the path or restore the file, and only then reset the row.
To rerun a row, you do what the documentation says you may do. Put ready back in its render-status cell, or empty the cell. The Bot picks up ready rows the next time it checks. Be aware of the overwrite behavior the documentation warns about. The Bot will overwrite existing files if it renders to the same output file name, which is why it recommends unique values in your id or output column. In a rerun that is exactly what you want, because the new good file replaces the old flawed one. It is exactly what you do not want if two different rows share a name and the second quietly replaced the first. Check for duplicate ids before the run, not after.
For rows that still say queued, do not assume they will be picked up by themselves. The documentation describes queued as the state the Bot sets when it retrieves a row and says nothing about the Bot re-evaluating queued rows on a later check. The documented way to ask for a render is ready. If rows are stuck on queued after a failure, setting them to ready is the documented route, and the 5-row test above should tell you whether your version needs it.
If the machine itself looks unwell, with After Effects frozen or closed, that is the ERR::AFXHOST case. Look at After Effects on that machine first, as the documentation says. Restart it. Re-enable the Bot. Then reset the affected rows. Do not reset them first, because a Bot that checks the sheet while the host is broken will just make new failures.
One last item belongs in this list because it bites people who run several machines. The documentation says multiple Bots can read the same data source. In that setup each Bot has a name set in Templater Preferences, and each row carries that name in a column called bot, which is how rows are assigned. If one Bot’s machine fails, the rows assigned to it are not described as moving to another Bot. Our FAQ makes the same point for Que and satellites. Assignment is manual. If you spread a batch across machines, a failed machine means you reassign its rows yourself by changing the value in the bot column. For the broader picture of running Templater across several machines, our piece on speeding up After Effects exports covers the optimization side.
The bottom line
The documented behavior of a failed Templater batch is smaller than most people hope and more useful than most people notice. Every row carries its own status. The two error codes separate a data problem from a host problem. The logs carry time stamps. Events and scripts let you build the alert you want. What the documentation does not give you is a statement about retries, about halting, or about what happens to the rows behind a failure, and a page that pretended otherwise would be doing you a disservice.
So before the long run, spend a little time on a five-row test with one deliberately bad media path. Write down what you see. Copy the old logs. Make your ids unique. Then leave it running with a clear conscience, and read the render-status column in the morning like the report it is. If you want a closer look at the pieces mentioned here, start with our Templater page, the guide to spot checks for catching bad data before a batch starts, and the article on flags in data sources. The learning section has the rest.
Questions about a particular failure come up often enough that we have collected the common ones below.
Frequently Asked Questions
Does Templater stop the whole batch when one row fails?
Our documentation does not say. It describes the Bot setting a failed row to an error code such as ERR::MEDIA or ERR::AFXHOST instead of done, and it describes the Bot continuing to check for new rows after the retrieved rows are finished. It does not state whether the remaining queued rows continue after an error. Run a five-row test with one deliberately missing asset on your own version and read the render-status column afterward.
What is the difference between ERR::MEDIA and ERR::AFXHOST?
ERR::MEDIA means Templater had a problem locating or importing a media asset, and the output video may still have been rendered with a media flaw in it. ERR::AFXHOST means After Effects itself hit an error, and the documentation says After Effects will likely have stopped operating normally. The first is usually a data or file fix. The second sends you to look at After Effects on the machine running Templater.
Will Templater retry a failed row by itself?
The documentation we reviewed does not describe an automatic retry. To rerun a row, the documented method is to put ready back in its render-status cell or empty the cell, then let the Bot pick it up on its next check. Fix the cause first, whether that is a missing file or a stopped host, or the row will fail again.
Which values can I type into the render-status column?
Only ready, or an empty cell. Templater writes queued, processing, done and the error codes itself. As of Templater 2.9.5 the Bot also overwrites formulas in the cells it updates with the formula’s result, so keep any helper formulas in a separate column.
Where do I find out what went wrong in the morning?
Start with the render-status column, then the log files in the directory set under Advanced in Templater Preferences. templater.log is the readable copy, templater.err collects errors, and each logged error carries a code, a description and a time stamp. Do not click Reset Log before a run without copying the old files, because it erases their contents.
Can I get an alert when a batch finishes or fails?
You can register an event script, for example on the After Batch event, to send an email or other notification. Event scripts require Templater Bot. The documentation does not state whether the After Job event fires for a failed job, so test that on your own setup before using it as your only failure alert.
What happens if two rows have the same output name?
The Bot will overwrite the existing file, because it runs fully automated. The documentation recommends unique values in the id or output column for every row. Check for duplicates before a long run, since a later row silently replacing an earlier one will not show up as an error.
