DNS propagation
You point a subdomain you already own at your ScaleBop project under Custom domains. Your default AWS URL keeps working while DNS and HTTPS finish, so a stuck custom domain does not take your application down — but it will not serve traffic until DNS resolves.
Custom domain setup only starts after your first healthy deployment, so if you see “Complete a healthy deployment first,” that is the missing prerequisite, not a DNS issue.
What the status means
Section titled “What the status means”The Custom domains section shows a progress status. The two that involve DNS are:
- Waiting for DNS — ScaleBop is waiting for you to add the DNS records it shows (CNAME, certificate validation, and — only in the nameserver-delegation mode — NS records), or for the records you already added to take effect.
- Certificate validation — your DNS records are in place and AWS Certificate Manager is validating the certificate for your hostname. DNS can still be settling, so this can take a few minutes.
You refresh the status from the same screen (Refresh status). You do not re-deploy to move status forward — DNS and certificates are provisioned outside the deploy workflow.
Causes
Section titled “Causes”| Symptom | What it means |
|---|---|
| Status stuck on Waiting for DNS | The DNS records shown have not been (fully) added yet, or you added them for a different hostname |
| Status stuck on Certificate validation | DNS propagated, but certificate validation has not finished yet — usually a wait-and-reroll situation |
| The domain resolves to the wrong thing | You pointed it at an old target, a typo, or the wrong record type |
| Nameserver mode, but DNS still not resolving | The NS delegation records (the two name servers ScaleBop showed) were not actually set at your registrar |
Most common causes
Section titled “Most common causes”These are, in practice, almost always one of a few things:
- Records not added for the exact hostname. Add the records shown on the Custom domains screen exactly — same hostname, type, and target value. A sub-domain typo is the frequent cause.
- Wrong DNS mode for your plan.
- Keep DNS at my registrar (CNAME) — the simplest path; add the CNAME record shown at your registrar/DNS provider. No nameserver changes.
- Manage DNS in Route 53 (nameserver) — you must set the NS records (the exact name servers ScaleBop listed) at your registrar. If DNS still does not resolve, this is usually the missing step.
- Propagation time. Even after the records are all added correctly, DNS propagation takes a few minutes (more if the domain or sub-domain has an old TTL or you have multiple authoritative providers). Wait, then Refresh status. Do not edit the records while it is settling.
- Multiple DNS providers. If the domain is registered at one registrar and DNS records live elsewhere (an alternate DNS provider), make the change where the records actually exist, not in two places at once.
Verify what the domain resolves to
Section titled “Verify what the domain resolves to”Check, independently of ScaleBop, what the hostname currently resolves to:
# Replace YOUR-EXAMPLE-HOSTNAME with your custom hostnamedig +short YOUR-EXAMPLE-HOSTNAME- No result / NXDOMAIN — the name is not delegated at all (nameserver mode) or a CNAME/NS record is missing at your provider. Add the missing records.
- A different target than what ScaleBop shows — either edit the record to the value ScaleBop shows, or re-generate records (ScaleBop shows the exact CNAME/NS for the current deployment).
- The right target — DNS is correct; wait for Certificate validation to finish, then Refresh status.
- Don’t re-run Deploy to “fix” DNS — DNS and certificates are provisioned independently of the deploy workflow. Re-deploying does not speed up DNS.
- Don’t edit records repeatedly while waiting — every edit resets the propagation clock.
- Don’t assume propagation is instant if the domain was previously registered with a different DNS provider; an old TTL can mean minutes (in practice up to ~24 hours for stale resolver caches), but usually just a few minutes.
When DNS resolves and the certificate is issued, the status on the Custom domains screen moves itself mapping_pending → active. If the domain resolves but the application then fails its post-deploy health check (it is the right DNS, but an app-level error), the issue is on the deploy side, not DNS — see Health check failed.