Skip to main content

Why is my render job queued, stuck, or slower than expected?

You submitted a job to Super Renders Farm, and now it's either just sitting there, or it's rendering but clearly taking longer than you budgeted for. Before you assume something's broken, it helps to know how the queue actually works — what decides when a job starts, what paying for a faster tier really buys you, and what a couple of in-between states actually mean.

This guide covers what determines your start time, what the priority tiers change in practice, why GPU jobs behave differently from CPU jobs, when a wait is normal versus worth a message to support, and why a render that's already running can still come in slower than expected.

What it looks like

  • Your job shows no visible progress right after upload or submission.
  • Status reads "in analyzing" or "in queue" for longer than the scene seems to warrant, with no frames back yet.
  • The job is actively rendering, but the pace is clearly slower than you estimated.
  • Everything looks normal, but you're not sure whether to keep waiting or flag it.

What actually decides when your job starts

Two separate things set your start time, and it's worth knowing which is which.

  • Which node pool your job resolves to. This is set by the machine template you choose at submission — your DCC, render engine, and CPU vs. GPU — not by the priority tier you pay for. Your job can only start once a worker in that matching pool is free.
  • Your place in the queue. Within that pool, jobs are ordered by priority, set by the tier you picked. A queued job starts as soon as a free worker reaches your position.

Picking a faster tier doesn't skip you past a pool that's simply full, but it does move you up faster once workers in that pool are available. There's no way to promise an instant start — pool availability and everyone else's jobs ahead of yours are real, variable factors.

What the priority tiers actually change

CPU rendering runs on a priority scale from $0.004 to $0.016 per GHz-hr — roughly ×1 to ×4 depending on the tier you choose. That range is a genuine speed tier, not just a price difference:

  • A higher tier raises your position in the queue, so you wait behind fewer jobs.
  • A higher tier also lets your job spread across more render nodes at once, so more of your frames render in parallel instead of one after another.

That combination — a better queue position plus more nodes running at the same time — is why a higher tier finishes sooner, not just why it costs more.

GPU jobs work differently. Every GPU job runs on a single dedicated GPU node, already placed at a fixed high priority by default — there's no tier to buy up from. The trade-off is that frames in a GPU job render one after another on that one machine, rather than spreading across multiple GPU nodes the way a higher-tier CPU job can. If you're wondering why a GPU animation is going frame-by-frame instead of all at once, this is why.

What "in analyzing" or "in queue" means

Before your job spends any render time, it goes through an automatic check: confirming the required job information is present, and scanning your scene for issues like missing textures or references, camera and output-path problems, and version mismatches. This step is separate from the queue itself, and a heavier scene can take longer to get through it.

If your job sits in "in analyzing" or "in queue" for much longer than its complexity would suggest, that's usually a sign the scene itself needs a look — not a longer queue.

When to just wait, and when to contact support

Waiting is the right call during busy periods, and while the in analyzing step works through a complex scene — neither is a fault on its own. It's worth reaching out if your job shows no progress after the queue should reasonably have cleared for your pool and tier, or if it's stuck in "in analyzing" or "in queue" much longer than the scene seems to justify. Both patterns usually point to something specific worth a look, rather than something you should keep waiting out.

Why an actively-rendering job can still run slower than expected

If frames are already coming back, but slower than you budgeted, the cause is usually in the scene rather than the queue:

  • Scene weight. Global illumination bounce counts, sampling and anti-aliasing settings, dense geometry, hair/fur/particle systems, heavy volumetrics, and large uncompressed textures all add directly to per-frame render time, regardless of tier or pool. If a render is slower than expected, your render settings are usually the first thing worth checking — a lower bounce count, a denoiser, or a lighter sampling setting can cut render time with little visible quality loss.
  • An ignored missing-asset warning. The submit-time check warns rather than blocks when it detects a missing texture or reference, so a scene with a gap can still go through, render, and come back looking wrong. Catching, fixing, and re-uploading that scene is often what actually feels like "this took forever," even though each individual render step ran at normal speed. See Missing textures or assets in your render for how to catch this before you upload.

Prevention checklist

  • Confirm your DCC, render engine, and plugin build against the supported versions and plugins matrix before you submit — a version issue can add a contact-support round-trip to your timeline.
  • Match your priority tier to your deadline, not just your budget. A tight deadline is exactly when a faster tier earns its cost back.
  • Keep render settings only as heavy as the shot actually needs — bounce counts, samples, and resolution all trade directly against render time.
  • Run your DCC's missing-asset check before every upload (see Missing textures or assets in your render) so a warning you skipped isn't the reason you're re-rendering.
  • If a job seems stuck, check what stage it's actually in before assuming the worst — "in analyzing" or "in queue" is normal for a stretch, especially on heavier scenes.

Related

FAQ

Q: Does a higher priority tier mean my job starts right away? A: Not instantly. A higher tier improves your position in the queue and lets your job use more render nodes at once, but it still needs a worker in your matching node pool to be free. The tier affects how fast you move once capacity opens up — not whether capacity exists yet.

Q: My job has been showing "in analyzing" or "in queue" for a while — is something wrong? A: Usually not. That stage is an automatic check that confirms your job's information and scans the scene for things like missing textures, camera or output-path problems, and version mismatches, and it can take longer on heavier scenes. If it sits there much longer than the scene seems to warrant, contact support so we can check what's holding it up.

Q: Why is my GPU render going frame-by-frame instead of all at once? A: GPU jobs run on a single dedicated GPU node per job, so frames render one after another on that machine rather than spreading across multiple GPU nodes at once. In exchange, GPU jobs get a fixed high priority in the queue by default.

Last updated: July 10, 2026