Your Webflow site is up. But is it actually working?
Webflow’s hosting almost never goes down, so a ping on your homepage will happily report “up” for weeks while your contact form drops every lead, your custom domain serves a certificate warning, or a renamed CMS slug 404s the page that earned you customers. Here is what actually breaks on a Webflow site, and the five checks that catch each one before a customer has to tell you.
Webflow’s reliability is what makes this hard.
On a self-hosted site, things break loudly: the server falls over and every check goes red at once. Webflow removes that failure mode almost entirely — and what’s left is a set of quiet ones. The pieces that break are the pieces Webflow doesn’t own: your registrar’s DNS, the certificate on the exact hostname a customer types, the mailbox your form notifications land in, the automation on the other end of that form, and the third-party script you pasted into a page four months ago. None of them change the homepage’s status code. So the one check most founders set up is the one check that can’t see any of them.
Six ways a healthy-looking Webflow site is losing you money
The form says “Thank you” and nobody gets the lead
Symptom: Submissions look fine on screen. The Webflow submissions list has them, or it doesn’t — either way no email, no CRM record, no Slack ping.
Fix: Follow the submission past the success message: check the notification recipient hasn’t bounced onto your email provider’s suppression list, confirm the Zapier/Make/n8n scenario is still switched on and in credit, and confirm the plan’s form-submission allowance hasn’t been used up for the month.
The custom domain broke, not the site
Symptom: webflow.io staging loads perfectly; your real domain shows a certificate warning, a redirect loop, or nothing at all.
Fix: Check that both the apex and www resolve to Webflow’s records, that only one of them is set as the default, and that the certificate covers the exact host a customer types. A DNS edit made months ago often only surfaces when the certificate next tries to renew.
A CMS slug changed and the page 404ed
Symptom: A blog post, product, or case study that ranked well now returns Webflow’s 404 page, and nothing in the Designer looks wrong.
Fix: Renaming a CMS item’s slug changes its URL and leaves no redirect behind. Add the old path to Webflow’s 301 redirects, and keep a keyword check on the handful of CMS URLs that earn you traffic or revenue.
You published to staging and thought you shipped
Symptom: The change is live for you on the .webflow.io URL and missing on the real domain — or a colleague’s unfinished edit went out with your publish.
Fix: Watch a keyword that only exists in the current published build, on the production hostname. That turns “did the publish actually reach customers” into a check instead of a memory.
Custom code or a third-party embed stopped running
Symptom: The page renders, but the booking widget, chat bubble, video, or analytics script is missing — usually after the vendor changed their script URL.
Fix: A status-code check can’t see this: the page is still 200. Use a visual check or a browser journey that asserts the embedded element is actually present and interactive.
Checkout or booking fails only for real customers
Symptom: Ecommerce or a booking embed accepts a click and then stalls, while an admin session works fine.
Fix: Run the buy or booking path as a logged-out visitor on a schedule, all the way to the confirmation step, so the break shows up before a customer finds it.
Paste this into your incident notes
Webflow site triage
[ ] Load the exact hostname a customer types (apex AND www), from
outside your network and in a private window.
[ ] Compare it against the .webflow.io staging URL. Both broken =
the site. Only the custom domain broken = DNS or certificate.
[ ] Check the live certificate on that host:
openssl s_client -servername HOST -connect HOST:443 </dev/null \
| openssl x509 -noout -dates -subject
[ ] Submit the real form. Then confirm it arrived where you READ it:
Webflow submissions list, notification email, CRM, Slack.
[ ] If the notification is missing, check the sending provider's
suppression / bounce list for that recipient address.
[ ] Check the Zapier / Make / n8n scenario is ON and still in credit.
[ ] Check this month's form-submission allowance on your plan.
[ ] Open your top 5 CMS URLs. A renamed slug 404s with no redirect.
[ ] Confirm the last publish reached production, not just staging:
look for text that only exists in the newest build.
[ ] Load a page with third-party embeds and confirm they render.Five checks, not one ping
A single homepage check is the wrong shape for Webflow. Nightlamp runs the layer that Webflow doesn’t: a dns_record and ssl check on the exact custom hostname, an http_keyword check that only passes when the current published build is really serving, a browser_journey that submits your contact form as a logged-out visitor, and an email_flow check that waits for the notification to actually land in a mailbox — not just for the form to say “Thanks!”. When one fails, an engineer reads the evidence and sends you the cause and the fix, rather than a red dot.
Want the checks that see past “the site is up”?
Start a trial, give us your domain and the form you care about, and Nightlamp watches the whole path — domain, certificate, published build, form submission, and the notification at the far end — then tells you in plain language what broke and what to change.
Start 14-day trial · no cardNewsletter
One real no-code incident + the fix, monthly
A post-mortem from a real no-code outage — what broke, how it was found, and the fix — once a month. Confirming also gets you the no-code incident runbook pack.
Double opt-in. One-click unsubscribe. No spam, ever.