You hand a research question to Gemini Deep Research, the screen says "researching…" and an hour later it's still saying the same thing. I have been running market and competitive research through Deep Research dozens of times a month since the early access window, as an indie developer at Dolice operating six sites — and at one point the "still running overnight, nothing returned" cases started multiplying.
The freeze looks like a generic "the server is slow" problem on the surface. After six months of watching it, I'm fairly sure there are actually five different causes hidden behind that single spinner, and only one of them is the kind that clears with a retry. The other four require you to change how you phrased the request, not how long you wait.
Here are the five causes I now recognize, and the move that gets past each one.
The five patterns behind a stuck Deep Research
In roughly 140 freeze incidents I have catalogued over the past six months:
- Too many parallel search steps (about 35% of incidents): when the research plan generates more than 30 parallel search steps, the back half tends to never complete
- Repeated access to a rate-limiting domain (about 25%): heavy repeated hits to certain SaaS documentation sites and a few news domains get throttled mid-flight, and the run silently stalls
- Research plan is too broad to ever close (about 20%): asks like "comprehensively cover the X industry's market trends and players and revenue models and outlook" collapse during the planning step
- Attached file analysis times out (about 12%): large PDFs or spreadsheets break the parse step
- Recitation block fires (about 8%): the request implicitly asks for long verbatim quotes, the safety system blocks the output, and the run goes silent
Only the first one ever heals on retry. The other four need a different prompt.
Cutting down parallel search step count
This is the most common failure. Deep Research starts by drafting a plan — "I will run these N searches in this order" — and a broad request can produce 40–60 parallel steps. From my logs, anything above 25 steps starts failing at noticeably higher rates.
The fix is to break the request into multiple smaller research jobs.
- ❌ Too broad: "Investigate the competitive landscape, revenue models, user trends, and outlook for the Japanese wallpaper app market"
- ✅ Split: "Identify the top 10 wallpaper apps in Japan by download volume and their operators" + separately "Identify the three dominant revenue models in Japan's wallpaper app market and the ARPU range for each"
I now target 20–25 plan steps per research job. That single change eliminated roughly a third of my freezes.
Avoiding repeated-domain throttling
For research that needs heavy reading from one or two domains — a SaaS reference site, a single API documentation tree — runs stall part way. The fix is two-fold:
- Phrase the request as a comparison across multiple sources rather than "go deep on this one site"
- When resubmitting a stalled run, explicitly say "skip the domains used previously and find alternatives"
The second instruction alone took my resubmit success rate above 80% in my own logs.
A checklist for "this plan is too broad"
Cause 3 is easy to catch if you look at the plan Deep Research displays before it starts. I now reject the plan and rephrase if any of these are true:
- More than 8 plan items
- The original request contains words like "comprehensive", "everything", or "the full picture"
- Four or more comparison targets
I run monthly competitive analyses for Lacrima and Mystery, the two blog sites I operate alongside the four AI labs. The early form was "research the revenue, traffic, and content strategy of our top 10 competitor sites" — and it froze nearly every time. The replacement is "compare the content strategy of the three Tier 1 competitors" and a separate "compare traffic scale across these five Tier 2 sites". Stuck runs essentially went to zero.
Pre-processing attached files
If your research includes attached files, the parse step can stall on big ones. From my experience, freezing risk rises when a single file is above 10MB or attachments total above 30MB.
- Slim PDFs to only the chapters that matter, under 5–10MB
- Convert spreadsheets to a CSV that contains just the columns you actually want analyzed
- OCR any image-only PDFs into text-PDF first
This matters more when calling Deep Research through the API. The browser version is more tolerant; the API gives up earlier.
Detecting a Recitation block in disguise
Cause 5 is the hardest to spot. Recitation block is the safety system that triggers when Gemini detects it is about to emit a long verbatim quote — and on Deep Research, it can silently end the run without an error message.
You will know it is recitation when:
- The run sits in "researching…" for ages, then quietly ends with nothing
- The same request fails at the same place on two or three retries
- Your prompt contains "quoting the original announcement" or "citing the paper's text" or similar verbatim-quotation language
Switch verbatim phrasing for summary phrasing: "summarize the announcement in three points", "extract the paper's key claims". On my news-monitoring research, that single substitution erased the stalls.
A pragmatic five-minute recovery routine
When it does freeze, here is the order I now follow:
- Close the tab and reopen it — the server-side session is often still alive and the result actually shows up
- If still nothing, cancel and resubmit the request split into pieces
- If partial results were already shown, screenshot them and request the missing pieces separately
- If you suspect cause 5 (recitation), strip verbatim-quote language and resubmit
After enough overnight runs that returned nothing, I gave up on the "fire one wide question before bed" pattern. The new pattern is "fire 3–5 narrow questions in sequence". Completion rate is steadily above 95% and the answers are sharper.
Deep Research is powerful, but it fails silently. I hope this helps anyone else who has spent a morning staring at a still-spinning research tab.