Your website is down, and customers are calling.
Then, as the support team drafts an email explaining the outage, you realize they can’t send it because your company’s email is affected too.
Now support has two jobs:
- Finding out what happened.
- Finding a way to tell people.
Meanwhile, customers keep retrying failed logins and opening tickets. An independent update channel gives them somewhere to check while your team works on the fault. You need to establish it before the outage.
Different providers can still depend on one domain
You may host your website with one provider and your email with another, but both can still depend on the same domain. They just look different in the output.
- Browsers use DNS records to find the website.
- Mail servers use them to locate the service that receives your email.
If the domain stops resolving, both can become unreachable. The effects depend on the failure and cached records. So email delivery may be delayed rather than immediately lost. The obvious fix, moving mail to a cloud provider, doesn’t remove the domain dependency.
Even a status page at status.example.com can fail for the same reason. So, hosting your status page on another domain helps if the web host goes down, but it still doesn’t make that address independent of example.com. That’s because if the parent domain stops resolving, customers may lose access to the status page as well.
Set up a customer update channel
Before an incident, check these four parts of your communications plan:
- Use an independent status address. Keep a provider-hosted address or a separately registered status domain available. Check its DNS and hosting dependencies; a second domain on the same failed DNS platform may not help.
- Publish the address in advance. Include it in onboarding and service communications. Offer status subscriptions where available, and use established social accounts to repeat updates. Customers need a way to find it without visiting your main website.
- Check how staff sign in. Verify that responders can publish without the primary email service or company single sign-on. Use MFA, and give designated backup staff secure access and a recovery procedure they can actually use.
- Test notification delivery. Confirm which sender domain and service deliver subscription notices. If emergency email uses a separate domain, configure and test its authentication and delivery beforehand. Customers should recognize the sender before an incident.
Rehearse the first update
Rehearse your first update like this. Make sure to include all the details about the scenario for everyone involved. That way your practice can more easily be remembered, and acted on when an incident really does take place. Use a story like this:
Imagine it’s an average weekday morning.
A customer calls their account manager because your website won’t load. They tried emailing support, but the message bounced.
So your engineers start investigating. Meanwhile, the customer has a team waiting to use your service. They need to know whether to postpone their work, whether there’s another way to get help, and when they’ll hear from you again.
Then your communications lead tries to publish an update, but the usual login requires a verification code sent to company email. That message isn’t arriving either.
This is the situation your exercise should recreate. Treat the primary website, email, and normal login route as unavailable. Have a backup staff member access your independent status page through the alternate login method and publish a private test incident or clearly marked exercise.
Ask someone outside the company to find that update using information customers already have. Can they reach it without visiting your main website? Can they recognize it as an official message? Confirm that test subscribers receive the notification and can open it without signing in through the affected domain.
Assign someone to customer communications so engineers can concentrate on restoration.
In this hypothetical incident, the first update could read:
“EXERCISE ONLY: Our website and support email are currently unavailable. We are investigating the cause and do not yet have an estimated restoration time. If your email to support bounced, please use the backup support number listed on this page. We will post our next update here by 10:00 a.m. Pacific Time.”
The backup number must be working and staffed. Publish the promised update even if service remains unavailable, explaining what you have confirmed since the last message.
Avoid filling “gaps” with reassurance you can’t support. If a customer asks whether their data is safe, an unreachable website alone cannot answer that question. Tell them what your team has verified and what remains under investigation.
Check where your incident alerts go
DomainSure’s services include DNS change notifications, domain and DNS monitoring, and account recovery and lock-release security. Ask us about the alternate notification channels described in our Web3 security paper, including Slack, Mattermost, and webhooks, and check the dependencies of the destination you choose.
Decide who receives those alerts and who publishes the customer update. Receiving a warning internally does not tell your customers what is happening.
Contact DomainSure’s sales team to request a free Domain Threat Assessment. Ask us to review the domain dependencies behind your website, email, and incident notifications. Include the status-page address and the accounts your responders use. The review should establish which of them remain usable when your primary domain doesn’t.
Apply for a Domainsure Invite
Get a Free Domain Health Check
Due to high demand: allow up to 24 hours for report delivery.
