When After Effects is not rendering, I start by separating a queue setup issue from a true render failure. The distinction matters because a missing output path, an unqueued item, a cache problem, a plugin conflict, or a Media Encoder mismatch each needs a different fix. The fastest wins usually come from the render queue itself, then from preferences, caches, and third-party effects.
Key things to check before you chase the wrong fix
- A render item marked Needs Output usually just needs a filename and save path.
- A Failed item means the render actually started, and the log file is where the real clue lives.
- I check disk space early because the app expects 10 GB free above the Media & Disk Cache setting.
- If the project is sent to Media Encoder, version matching and parallel encoding settings matter more than people expect.
- Safe Mode is useful because it disables third-party plugins and extensions without changing the project itself.
Why the render stops in the first place
I always look at the status column first because it tells me whether the problem is administrative or technical. The help docs note that Failed means After Effects actually tried to render and could not finish, while Needs Output simply means no destination file was set. That distinction saves time: one case needs a path, the other needs troubleshooting.
| Status | What it usually means | What I do next |
|---|---|---|
| Unqueued | The item exists, but it is not ready to render. | Enable the render column and queue it. |
| Needs Output | No output filename or path has been set. | Choose a writable output location. |
| Queued | The job is ready to go. | Start the render and watch for the frame where it stops. |
| Failed | The render started, then hit an error. | Open the log file and inspect the exact failure point. |
If the status is Failed, I do not guess. I open the log, note the frame number or module that broke, and use that clue to decide whether the issue sits in the comp, the output module, or the machine itself. Once that foundation is clear, the fastest fixes become much easier to rank.
The fastest fixes to try first
My first pass is deliberately boring, because the boring fixes solve a surprising number of export problems. I confirm the output path, save into a local folder with a short path, and make sure the destination is writable before I spend time chasing effects or codecs. If the file is meant to land on a disconnected drive, a network location, or a folder with odd permissions, the render can fail for reasons that look more complicated than they are.
- Set the Output To path explicitly instead of leaving it unresolved.
- Save the export to a local folder first, then move the file later if needed.
- Free up space before testing again. The app checks for 10 GB free above what is set in Preferences > Media & Disk Cache.
- Close other heavy apps so the render test is not competing with background memory pressure.
- Rerun the same comp after a fresh save, because a temporary save issue can masquerade as a render bug.
If that still does not move the needle, I go one level deeper and isolate the export path, because failures that involve another app usually behave differently from failures that stay inside After Effects.
When Media Encoder is involved, version and renderer settings matter
Plenty of people assume the problem lives in the composition when the real issue is the handoff to Media Encoder. That is especially common when the render queue is fine until the job is sent there. In that case, I check the app pair first: both apps should be updated, and they should be on the same version before I trust the export pipeline.
| Symptom | Likely cause | Best next move |
|---|---|---|
| The job fails only after Queue in AME | Version mismatch or a Media Encoder preference problem | Match the versions, then reset Media Encoder preferences if needed |
| The export hangs or behaves erratically | Parallel encoding conflict | Turn off Enable Parallel Encoding |
| The render fails on complex effects but not simple footage | Renderer or GPU path issue inside Media Encoder | Switch the renderer to Mercury Playback Engine Software Only |
| The same comp works elsewhere | Local preferences or cache corruption | Reset Media Encoder preferences after closing both apps |
I treat this section as a fork in the road: if the composition renders natively but fails through AME, the fix is often on the export side, not in the project. That is why I always test both paths before changing the composition itself.
Rule out plugins, preferences, and cache corruption
When the failure repeats at the same frame or happens only with specific effects, I start suspecting third-party plugins and stale preferences. The most useful test is Safe Mode, because it disables third-party plugins and extensions without asking me to dismantle the whole project. If the render works there, the project is telling me that either a plugin is unstable or the preferences need to be rebuilt.
- Restart in Safe Mode and try the render again.
- If it succeeds, disable recently added plugins or extensions one by one.
- Reset preferences from the Startup & Repair area if the issue persists.
- Use Empty All Caches when cache corruption or storage bloat looks likely.
I do not reset everything at once unless I have to. A clean cache or a new preference file can fix a stubborn render, but wiping too much too early makes it harder to tell what actually caused the break. Once the software layer looks healthy, I move to the machine and mode checks that can mimic a project problem.
Check for render engine mode and compatibility warnings
One easy mistake is launching the wrong app mode. If After Effects opens in Render Engine mode, menus can look disabled because the app is acting like a node instead of the full editor. The help docs note that can happen if you launch the Render Engine icon instead of the normal application icon, or if an ae_render_only_node.txt file is present in the Documents folder. In either case, the fix is to open the normal app or remove that file.
I also pay attention to the Startup & Repair options that expose system compatibility issues. That report is useful when the problem is not a bad comp but a machine-level mismatch, a driver warning, or an environment issue that only shows up during rendering. If I see a compatibility alert, I treat it as a real clue rather than a background annoyance.
| What I see | What it usually points to | Why it matters |
|---|---|---|
| Disabled or oddly limited menus | Render Engine mode | The app may not be running in the normal editing environment |
| Repeated failures on a healthy project | Compatibility or system issue | The machine may be interfering with the export process |
| Failures on one workstation but not another | Local environment difference | Preferences, drivers, or plugins are the likely divide |
| Failure at the same frame every time | Corrupt layer, effect, or source media | The frame pinpoints where the project breaks |
At this stage, the project usually stops being a mystery and starts looking like a specific class of failure. The last step is knowing how to recover cleanly when none of the quick fixes are enough.
The fallback workflow I use for stubborn projects
When a project keeps failing, I stop trying to export the whole thing at once and switch to isolation. I duplicate the comp, disable the most suspicious effects first, and render shorter ranges so I can narrow the failure to a specific section. That approach is slower in the short term, but it is much faster than re-rendering a full timeline over and over with no new information.
- Render a 5- to 10-second range around the failing frame.
- Temporarily disable third-party effects, expressions, and heavy particle or blur stacks.
- Replace problematic footage with a proxy or transcode it to a cleaner intermediate format.
- Pre-render expensive precomps so the final comp has less to process.
- If the final movie still fails, render an image sequence first and assemble the delivery file afterward.
I use image sequences as a recovery tool, not as a permanent dodge. They are valuable because they preserve progress even when a final movie export refuses to finish, and they often reveal whether the problem lives in one frame or in the delivery format itself. If you work through the render queue status, cache, plugins, Media Encoder handoff, and system mode in that order, you usually get from vague failure to a specific cause before the project burns another hour.
