G: Short version: yes, there do appear to be ongoing quirks and intermittent failures with the ChatGPT export system, and your experience is consistent with what a lot of people have reported — especially the “nothing seems to happen after verification” behavior and the “multiple retries may silently cancel previous exports” issue. citeturn0search2turn0search4turn0search5

A few things stand out from what you described:

• The desktop flow where it asks you to verify identity and then silently drops you back into chat without a clear “export queued” confirmation has been reported by others. citeturn0search5turn0search20
• Several users report exports simply never arriving, even after repeated attempts. citeturn0search2turn0search5turn0search20
• There are also repeated reports that submitting a new export request cancels the prior one and resets the queue. citeturn0search4
• OpenAI’s own documented/export ecosystem expectation appears to still be “can take up to 7 days,” even though many people get it within hours. citeturn0search14turn0search25

The important part for your situation is this:

You may have accidentally created a self-reset loop.

If:

1. the system accepted at least one request,
2. then later attempts partially failed visually,
3. but still counted internally,

…then each retry may have invalidated the previous export job before it finished. That would explain:

• why only one email ever appeared,
• why later attempts seem invisible,
• why nothing arrives,
• and why the timing feels inconsistent.

The phone-vs-desktop discrepancy also matters. There are scattered reports suggesting the mobile UI sometimes fails to fully initiate the export flow even when the button is pressed. The desktop version at least reaches the verification stage, which implies it’s getting farther into the pipeline. citeturn0search5turn0search14

Based on the current reports, the safest strategy is probably:

1. Use desktop browser only.
2. After verification, wait and see if you get the small green success toast/message.
3. Once you submit ONE request, stop retrying entirely for at least 48 hours — ideally the full 7 days OpenAI documents.
4. Watch:
   • inbox
   • spam
   • promotions
   • “all mail”
5. When the email finally arrives, download immediately. The links still appear to expire after 24 hours. citeturn0search4turn0search9turn0search18

One additional thing: if you have an unusually large conversation history, people report longer delays and occasional failures. citeturn0search15turn0search24

And unfortunately, your “20 hours then missed the link” story is almost perfectly aligned with the current system behavior:

• export arrives late,
• link expires quickly,
• retrying may reset queue,
• UI feedback is weak.

So your concern is reasonable; this does not sound like you simply hallucinated pressing the button wrong four times.

G: Yeah, and that mismatch is the part that would annoy me too.

If the UI says “up to 24 hours,” and the actual backend documentation says “up to 7 days,” then the user is being trained to interpret delays as failure. That creates exactly the retry-loop problem we just talked about.

And importantly: the “7 days” thing is not rumor anymore. It is now explicitly in OpenAI’s own help documentation. citeturn0search2turn0search1turn0search6

More critically, the same official documentation also says this:

“Only the most recent export request will be fulfilled; any earlier requests are canceled.” citeturn0search2

That single sentence explains a lot of the weird behavior people are seeing.

Because if:

• the frontend gives weak/no confirmation,
• exports are delayed,
• and retries cancel prior requests,

…then users naturally sabotage their own queue position while trying to fix what looks like a broken request.

As for what’s “actually” happening under the hood:

Nobody credible outside OpenAI seems to know the exact technical failure mode right now. I could speculate, but that would just be dressing guesses up as architecture.

What does seem believable from the evidence is:

• This is probably not a single broken server or accidental unplugging event.
• It behaves more like a queueing / job orchestration bottleneck.
• Large exports likely get batch-processed asynchronously rather than generated live.
• The system may prioritize stability over responsiveness, meaning requests enter a delayed processing pipeline instead of immediate execution.
• UI/backend synchronization appears poor.

The strongest evidence for “queue/backlog problem” rather than “hard outage” is:

• some users get exports in hours,
• some in 2 days,
• some after retrying,
• some after support escalation,
• and some after long silence. citeturn0search3

That pattern looks more like:

overloaded or unreliable async processing

…than:

total system failure.

And there’s another subtle clue:

The export is not just “your chats.”

The ZIP apparently contains:

• account metadata,
• settings,
• conversation structure,
• timestamps,
• uploaded file references,
• other account-linked data. citeturn0search2turn0search6

So this is closer to a privacy-compliance export pipeline than a simple “download transcript” feature.

That matters because systems built for:

• GDPR/privacy compliance,
• legal traceability,
• anti-abuse validation,
• account verification,

…are often architected conservatively and asynchronously. They tend to be slow, batch-oriented, and cancellation-prone.

Which means the actual backend may not have been designed for:

tens or hundreds of thousands of users suddenly panic-exporting giant archives simultaneously.

And judging by Reddit/community complaints, there has been a noticeable surge in export activity over the past several months. citeturn0search3

So the most believable explanation right now is probably:

• the export system is technically functioning,
• but overloaded and badly communicated,
• while the frontend still presents it like a near-real-time feature.

Which is a UX design problem almost as much as a backend one.

G: That’s not an unreasonable systems-level guess. I wouldn’t present it as fact, but it fits several observed symptoms better than “single random bug.”

Especially this part:

“trying to avoid exporting the entirety of someone's image history”

That is exactly the kind of thing that can quietly turn a “simple export” feature into a monster.

Because once images enter the equation, the system stops being:

• “zip some JSON”

…and becomes:

• locate binary assets,
• verify ownership,
• check retention policies,
• resolve references to deleted items,
• reconcile CDN/object-store pointers,
• avoid exporting shared/internal/generated assets incorrectly,
• avoid exploding archive size,
• avoid timing out signed URLs,
• avoid leaking cross-session metadata.

And if the architecture evolved over time rather than being designed from day one for complete account exportability, then you can get ugly edge cases like:

• conversations pointing to stale assets,
• uploads whose metadata exists but binaries were lifecycle-moved,
• generated images stored differently from uploaded images,
• partial deduplication systems,
• references across storage tiers,
• or exports recursively trying to enumerate gigantic attachment trees.

Your “feedback loop chewing memory/disk/queue resources” theory also maps surprisingly well onto the behavior pattern:

• intermittent success,
• long stalls,
• retries worsening things,
• partial throughput returning later.

That feels like:

workers getting jammed by pathological jobs in a shared async queue.

Not necessarily RAM specifically — could just as easily be:

• worker exhaustion,
• storage I/O saturation,
• object retrieval bottlenecks,
• deadlock avoidance,
• retry storms,
• or queue poisoning from malformed jobs.

The reason your rollback idea also makes sense is because: if engineers discover that:

1. a new export optimization introduced corruption or runaway processing,
2. but rolling back risks invalidating in-flight jobs,

…then they may:

• throttle the queue,
• drain jobs slowly,
• intermittently pause processing,
• deploy partial mitigations,
• or temporarily serialize exports to reduce damage.

That produces exactly the “sometimes works, sometimes silent” feel users describe.

And honestly, the biggest clue that something nontrivial is happening internally is the cancellation behavior:

“Only the most recent export request will be fulfilled.”

That is not how you architect a robust consumer-facing export pipeline if capacity is abundant and jobs are cheap.

That sentence sounds like:

“we cannot safely/process-efficiently support duplicate concurrent export jobs per account.”

Which strongly implies resource intensity or state-management complexity somewhere in the pipeline.

So while your exact mechanism may or may not be right, the broader shape of your suspicion —

backend export orchestration under strain due to large/stateful data assembly problems

— is pretty plausible.

G: Yes. Structurally, it does.

Not necessarily maliciously, but the design naturally shifts blame outward because the visible interaction pattern encourages behavior that invalidates the process.

From the user’s perspective:

• they click export,
• receive weak or ambiguous feedback,
• wait the advertised window,
• nothing arrives,
• retry,
• and unknowingly cancel the previous request.

So later, support or diagnostics can truthfully say:

“Only one active request existed,” or: “The latest request reset the queue,” or: “The previous export expired,”

…while the user experiences it as:

“I followed the instructions repeatedly because the system looked broken.”

That creates a kind of procedural blame trap:

• the system behavior induces corrective action,
• the corrective action worsens the outcome,
• and the logs then reflect the worsened state as user-generated.

It’s a classic UX/backend mismatch problem.

A well-designed system usually avoids this by doing at least one of:

• persistent status page (“Queued / Processing / Estimated completion”),
• visible warning before retry (“This will cancel your existing export”),
• idempotent requests (“already queued”),
• downloadable status tokens,
• or explicit emails confirming queue placement.

Without those, users are forced to infer state from silence, and humans are extremely bad at interpreting silence in asynchronous systems. Silence usually gets interpreted as failure, especially after the stated ETA passes.

So the issue is not merely:

“the user made a mistake.”

It’s:

“the system incentivized a predictable mistake and gave poor visibility into consequences.”