Artifacts stop appearing and every guide says the same four generic fixes. Here's the order that actually separates a setting on your side from an outage on theirs — starting with the one documented cause that produces total failure.
Artifacts stop appearing. You reprompt, you reload, you try a different browser, and somewhere in the third search result someone tells you to clear your cookies.
The problem with most of that advice isn't that it's wrong — it's that it's undirected. Four generic fixes applied in random order will eventually stumble onto the cause, and you will have no idea which one worked or whether it will happen again.
There is a better order, and it starts with the one cause that is documented rather than folklore.
Anthropic's documentation says artifacts require Cloud code execution and file creation to be turned on — in Settings > Capabilities, or Organization settings > Capabilities on Team and Enterprise plans.
That is worth reading twice, because of what it implies about symptoms. This isn't a feature that degrades — with the toggle off, artifacts don't work, and the failure looks identical to a serious platform fault. People spend an hour rewriting prompts against a switch.
It's also worth re-checking even if you're certain you never touched it. Settings state can come back different after an update, and "I definitely didn't change that" is not evidence about the current value. Look at it rather than remembering it.
One change on their side is worth knowing about too: artifacts made in a chat before 16 September 2026 are now what Anthropic calls legacy artifacts. They keep working and you can still publish and share them, but new ones aren't made that way any more — what you make now is saved to the Artifacts tab in the sidebar, where you can also start from a template.
If settings are fine, the next question is the one that splits the whole problem in half, and it takes thirty seconds.
Open a brand-new conversation and ask for something simple. A small but complete single-file HTML page — a heading, a paragraph, a coloured background. Nothing clever, nothing that could plausibly be your fault. Keep it a whole page rather than a snippet: Claude typically only makes an artifact for self-contained content of more than about fifteen lines, so a tiny request can come back as plain chat text without anything being broken.
The reason this check earns its place is that it is the only one that can tell you to stop working. Everything else narrows the search; this one can end it.
Long conversations accumulate. An artifact that has been iterated twenty times, reverted once, and branched somewhere in the middle is carrying a lot of history, and later edits have to reconcile with all of it.
If a specific artifact has stopped updating sensibly while fresh ones are fine, the fastest route is usually not to argue with the existing thread. Start a new conversation, paste in the current version of the artifact as code, and continue from there. You lose the conversational history; you get a clean slate that behaves.
Also worth ruling out here: you may be looking at a different version of the chat. Editing an earlier message creates a separate version of the conversation with its own artifacts, so a working artifact can seem to have vanished or reverted when you're simply on the other branch. Check which version of the chat you're in before concluding anything.
Only at this point is your own code a reasonable suspect — and note this is a different failure from an artifact that publishes and then opens as a white screen. If the artifact renders inside the chat and the published link is blank, that's a separate diagnosis with its own three branches, covered in which of three things broke when a published artifact is a blank page.
For an artifact that won't render in the chat at all, the usual causes are ordinary: a syntax error, a library it references that isn't reachable, an external resource it assumes. Asking Claude directly to check the artifact for errors is more efficient than reading it yourself, because it has the code in front of it.
And if what you're hitting is a wall rather than a bug — it needs a server, a database, live data — that isn't a fault at all. Artifacts documented limits rule those out by design, and no debugging session recovers from a category error.
This is the part most troubleshooting guides skip, and it's the part with a deadline attached.
If you've confirmed it isn't your settings and a minimal test artifact also fails, further attempts are not an investigation — they're waiting, with extra steps. The useful move is to change what your delivery depends on.
If any version of the work still exists, get it out as a single self-contained HTML file. One file, scripts and styles inlined. The export checklist covers what exports quietly leave behind, which matters more than usual when you're working around a platform that's already misbehaving.
A file on your disk opens in any browser with nothing else involved. You can check it renders correctly by dropping it into a viewer — that runs entirely in your browser, so it works regardless of what's happening upstream. From there, delivering it is your decision: email the file, or put it on a link you hold so the recipient gets a page rather than a download. On miinideck that link stays out of search by default and keeps the same address when you replace the file, so a fix you make tomorrow doesn't invalidate what you sent today.
Being honest about what this does and doesn't solve: it gets finished work to someone while the platform is unavailable. It does not let you keep building — for that you're waiting like everyone else.
If you got to the end and the answer was "it's upstream", that's worth reporting, and your report will be unusually useful. Most incoming reports require support to rule out settings and user-specific causes first. Yours already has: mention that you tested with a trivial artifact in a fresh conversation with code execution enabled, and you've skipped the entire first round of triage.
Claude's documented behaviour described here was checked against Anthropic's own support documentation on 29 September 2026. Platform behaviour changes; confirm on their side before relying on it.
Settings, then a trivial artifact in a fresh conversation, then the conversation, then the code. The second step is the important one, because it's the only one that can tell you the problem isn't yours — and once you know that, the right move is to export what you have and deliver it, not to keep pressing the button.
A disabled Publish button isn't one bug — it's four different situations wearing the same grey. Only one of them clears if you try again. Here's how to tell which one you're looking at, and how to get the page to the person waiting for it either way.
The message is about Anthropic's side, not yours, and it usually clears on its own. The risk isn't the outage — it's what people press while waiting. Here's the safe order of operations, and how to get the work out of the artifact while you wait.
You built something in Claude, came back weeks later, and it's gone. Usually it isn't deleted — it's sitting inside a conversation you can no longer find. Here's how to get it back, and the one case where it really is unrecoverable.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.