What to Do If Your JS.ORG Subdomain Request Has a Naming Conflict or Doesn't Go Live

JS.ORG subdomains are requested by pull request, and the site states your new URL should go live within 24 hours. If it doesn't, the cause is almost always one of three things: a naming conflict, a missing or misplaced CNAME file, or a GitHub Pages custom domain setting that wasn't completed. Work through the checks below in order, and respond on your pull request if the maintainers raise a question.

First, confirm what "not live" means

Before changing anything, separate the two possible states:

Your pull request is still open or has comments. The request hasn't been merged, so nothing should be live yet. Go to the pull request and read the maintainers' comments.
Your pull request was merged but the URL still doesn't resolve. This points to a DNS or GitHub Pages configuration problem on your side, not a JS.ORG problem.

The site notes you should keep an eye on your pull request in case of a naming conflict or a question from the JS.ORG side, so the pull request is the first place to look.

Handling a naming conflict

A conflict happens when the subdomain you picked is already taken or clashes with an existing JS.ORG domain.

Open your pull request and read the maintainers' comment identifying the conflict.
Choose an alternative subdomain. Per the site, for a GitHub Pages URL like http://foo.github.io/bar, either foo.js.org or bar.js.org is possible — so if one is taken, the other is usually a valid substitute. The wiki linked from the site has more detail on eligible names.
Update the CNAME file in your repository to match the new name exactly (see below).
Update the subdomain entry in your pull request so it matches the new CNAME value.
Reply on the pull request confirming the change, then wait for it to be merged.

If the maintainers ask a question rather than flagging a conflict, answer it directly on the pull request — an unanswered question is itself a reason the request stalls.

Check the CNAME file

This is the most common self-inflicted failure. The site's step 3 is specific about the requirements:

The file must be named exactly CNAME (no extension).
It must contain a single line matching your chosen domain, for example foo.js.org, written without quotes.
For project pages, it must be added to the gh-pages branch, not the default branch.

If your CNAME has a trailing slash, quotes, extra whitespace, or the wrong domain, GitHub Pages won't serve the custom domain correctly. Fix the file, commit it to the correct branch, and give GitHub a few minutes to rebuild.

Verify the GitHub Pages custom domain setting

The CNAME file and the repository's Pages settings need to agree. In your repository's GitHub Pages settings, confirm the custom domain field shows the same domain as your CNAME file. GitHub's own "Custom URLs" documentation, which the site points to for troubleshooting, covers the exact steps for your account type. If the field is empty or shows a different domain, set it to your JS.ORG subdomain and save.

If the pull request was merged but the URL is still dead

Work through this sequence:

Wait out the window. The site says the URL should go live within 24 hours of the request being handled. Check again after that period before assuming something is broken.
Re-check the CNAME file on the branch GitHub Pages actually serves. A file committed to the wrong branch has no effect.
Re-check the Pages custom domain setting and re-save it if needed — saving triggers GitHub to re-verify the domain.
Confirm the pull request was actually merged, not just approved or closed. Only a merged request adds your subdomain to the JS.ORG domain list.
If all of the above are correct and 24 hours have passed, comment on the merged pull request describing what you've verified (CNAME contents, branch, Pages setting, time elapsed). That gives the maintainers the information they need to investigate.

What JS.ORG does and doesn't control

Worth keeping in mind while troubleshooting: JS.ORG provides the subdomain and the URL, but the site states that as repository owner you keep complete control over your published content — and all rights and duties that come with publishing a website remain your responsibility. That means content problems, broken builds, and GitHub Pages misconfiguration are on your side; the subdomain record and the naming list are on theirs. Directing your question to the right side saves a round trip.

Your page also has to provide reasonable content with a clear connection to JavaScript. If a request is declined or questioned on those grounds, the fix is to adjust the content, not the DNS.