When a CreatePorn generation appears stuck, preserve its record before submitting another identical job. The useful evidence connects the generation, its status and any Gem change. Repeated retries can create several separate events while leaving the original problem unexplained.
The vendor’s help center distinguishes missing output, blank results and errors where Gems were not returned. Those cases need different descriptions. A busy queue is also not the same as a completed job whose result you dislike.
Classify the visible problem
Start with what you can actually observe. Do not describe a backend cause that you have not established.
| Observation | Record first | Question to investigate |
|---|---|---|
| Job still shows a waiting or generating state | Job link, queue and start time | Is it progressing or affected by a service issue? |
| Job reports an error | Exact message and balance change | Was the action charged or returned? |
| Completed item is blank or missing | Creation link and screenshot | Is delivery or display failing? |
| Output exists but looks wrong | Style, inputs and visible defect | Is this a quality or supported-input issue? |
If you only know that an item is slow, say that. Do not turn a delay into a claim that your account is blocked or that the service has lost the file.
Preserve the sequence before changing anything
Record the local time with timezone, the style or engine shown, the queue used and the generation link. Copy the exact error wording if one appears. Note the Gem balance before and after when you have those values; do not reconstruct an exact starting balance from memory.
Capture a screenshot that shows the relevant status without exposing unrelated account or payment details. If the item has a stable link, retain that link privately even when the preview fails. It can identify the job more clearly than a thumbnail description.
The support article asks for these kinds of contextual details. Preparing them early makes the report useful even if the state changes while support investigates.
Do not treat every problem as a refund claim
CreatePorn publishes a general no-refund policy with particular Gem exceptions. The current help page includes platform failures and certain support-assessed cases. That does not mean every disliked image automatically qualifies, and a Gem adjustment is not necessarily a cash refund.
Describe the observation before requesting an outcome. “The job displayed an error at this time and my balance did not change afterward” is more useful than starting with an assumption about what the vendor owes.
If you are unsure which policy applies, ask support to identify the relevant case. Keep any answer with the generation record instead of extrapolating it into a promise about future jobs.
Check whether the issue repeats in the same way
A single local display problem and a series of separately charged failed jobs are different situations. If you already have multiple affected items, list their identifiers and times without creating more examples solely to prove a point.
Avoid making several simultaneous changes to the browser, prompt, engine and queue. You would then have difficulty explaining which condition belonged to the original event. Start by preserving the existing evidence and following the official support guidance for that condition.
Do not bypass access restrictions or upload private material to an unrelated diagnostic site. A basic generation report should stay with the official help route.
Send one coherent report
A concise message can follow this structure:
On [date, time and timezone], creation [link] showed [exact status or error]. I used [style/engine] and [queue]. The observed result is [missing, blank or failed]. My recorded Gem change is [values, if available]. Please investigate this job and confirm the appropriate next step.
Add a redacted screenshot and the relevant input details when they are needed to reproduce the problem. If your inputs contain private information, ask which details support actually requires before forwarding them.
Keep a stopping point
Wait for a meaningful change or a support answer rather than repeatedly submitting the same job. If you later try a different task, record it as a new attempt with its own cost and identifier.
The immediate goal is a clear account of one event. That is more likely to lead to a useful explanation than a collection of unlabelled screenshots and repeated charges.