What happens when a small business website certificate expires over a long weekend?

This case study is an illustrative scenario. The business is a composite and the numbers are worked examples to show the method, not results from a named client.

What happens when a small shop's certificate lapses on a long weekend?

A small Canadian shop sells online and takes bookings through its website. Its certificate lapses at 6:40 on a long-weekend Saturday. From that minute, every visitor sees a security warning, the booking page will not load, and the owner, who is at the cottage, has no idea until customers start complaining on Monday.

The composite business is a bike and ski shop in a mid-sized Maritime town: two owners, four staff in season, a repair bench that runs on appointments, and a small online store for parts and gift cards. About two thirds of repair bookings come through the website. The rest arrive by phone. The site was built by a local freelancer three years ago, and the hosting account sits on one owner's credit card.

Here is what happens without monitoring. The card on the hosting account was replaced in the spring. The hosting plan still runs, but a small add-on that handled automatic certificate renewal quietly stopped. Nothing looks wrong for months, because the old certificate is still valid. Then it expires on a Saturday morning.

Customers who type the address see a full-page warning that the connection is not private. A few click through. The booking widget, served from a third-party system, refuses to load inside an insecure page. Two customers message on social media; nobody is watching the shop's account. On Monday at 10, a regular walks in and says the website has been "hacked" all weekend. By then the site has been effectively closed for about 75 hours.

Why do website certificates lapse at small businesses?

Certificates lapse because renewal depends on automation nobody watches. A hosting move, a changed DNS record, an expired card or a disabled add-on can break renewal silently. The old certificate keeps working until its expiry date, so the failure shows up weeks or months after the change that caused it.

The industry is making this more pressing, not less. In 2025 the CA/Browser Forum, the body where certificate issuers and browser makers set the rules, adopted a schedule that reduces the maximum validity of public TLS certificates from 398 days to 47 days, in steps starting in March 2026 and ending in March 2029 [1]. All four browser makers voting in the Forum, Apple, Google, Microsoft and Mozilla, voted for it [1]. Let's Encrypt, the free certificate authority many small hosts use, issues 90-day certificates today and plans to reach 45 days by 2028. It says manual renewal is not recommended and that subscribers should have monitoring that alerts when a certificate is not renewed as expected [2].

There is a second change owners miss. Let's Encrypt used to email subscribers before a certificate expired. It ended those expiration emails on June 4, 2025, and points anyone who still wants warnings to separate monitoring services [3]. A shop that relied on that email as its safety net no longer has one.

Shorter lifetimes are good for security, and they make renewal routine. They also mean more renewals per year, and so more chances for a broken renewal to reach customers. The fix is not to renew by hand. It is to watch the automation.

What would website monitoring catch before customers notice?

Watch checks the things that make up the storefront: the website answering, the certificate's expiry date, the domain registration and DNS, and the email server. Checks run as often as every 60 seconds, so a certificate that is not renewing raises a warning well before customers see anything, and an outage raises an alert within minutes.

For this shop, a sensible set of Watch checks looks like this:

• Home page and booking page. Two website checks, so a working home page does not hide a broken booking page.
• Certificate expiry. A warning when the certificate is getting close to its end date and has not been replaced. This is the check that matters most in this story, because it fires while there is still time to fix the problem during business hours.
• Domain registration and DNS. Whether the domain is nearing expiry and whether it still points at the right server. For generic domains such as .com, ICANN's recovery policy requires registrars to send reminders about a month and about a week before expiry, and to interrupt the domain's existing DNS path if it is deleted soon after expiring [4]. Those reminders go to whatever email address is on file, which is often a former employee's or the freelancer's. The .ca registry has its own rules, so check with your registrar.
• Email. Whether the mail server that receives customer replies and order notices is reachable, because the same hosting or DNS mistake that breaks the website often breaks mail too.

That is six or seven checks out of the 60 Watch allows, leaving plenty of room for the shop's phone line and anything else it wants watched.

How does the alert reach the owner on a long weekend?

Watch sends alerts to your team by SMS, email or voice, and you choose who receives them. The point is that the alert reaches a person with a phone in their pocket, not an inbox nobody opens on a holiday. Each outage also opens a war room: one timeline of what failed, when, and what was sent.

In the monitored version of the scenario, the story changes in two places. Several days before expiry, the certificate check warns that the certificate is close to its end date and has not renewed. The owner forwards the warning to the freelancer on a Tuesday, and it is fixed in an afternoon. Nobody outside the shop ever knows.

Suppose the warning is missed anyway. At 6:41 on Saturday, the website check fails and a voice call goes to the owner at the cottage and a text to the second owner. The war room shows the time of the first failure, the certificate error, and who was alerted. The owner phones the freelancer, or the hosting company's support line, and asks for the certificate to be reissued.

Meanwhile the shop's public status page, which comes with Watch, says online booking is down and asks customers to call or email. A pinned social post links to it. Watch does not fix the certificate; you respond, and MapleMonitor alerts. What it removes is the 75 hours of nobody knowing.

How do you work out what the outage costs?

Count what stops, not what the website costs. Multiply the hours the site is down by the bookings and orders you normally get per hour, reduce for customers who come back later, then add the staff time spent cleaning up. Use counts and your own average values so the method fits your business.

The table below is a worked example for the composite shop. The figures are illustrative; replace every one with your own.

To turn the table into money, multiply lost bookings by your average booking value, lost orders by your average order value, and staff-hours by your loaded hourly cost, then add the emergency hours. Do the same for the monitored line. The difference is the most one weekend like this is worth avoiding. Compare that with the Watch price on the pricing page, and remember certificates will be renewed several times a year from now on [1].

Does a website outage hurt my Google ranking and reputation?

A weekend certificate outage is mainly a customer problem, not a search problem. Google says server errors make its crawler slow down temporarily and that indexed pages are kept but eventually dropped if errors persist. The bigger cost is customers who conclude you are closed, careless or hacked.

Google's documentation is specific about how its crawler treats a site that returns 5xx server errors: it slows crawling temporarily, keeps already indexed URLs for a time but eventually drops them, and ignores content from pages returning those errors [5]. A certificate warning is not the same as a server error, but when a lapsed hosting account or a failed renewal takes the whole site down, this is how search sees it. Days of errors matter; a three-hour blip rarely does.

Reputation is harder to count and usually costs more. The regular who says "hacked" is telling other people the same thing. A security warning on a site that takes card payments is the one message that makes customers hesitate to come back. Online sales are a growing share of how Canadians shop: Statistics Canada reports that retail e-commerce accounted for 6.8% of total retail trade in May 2026, and that figure leaves out online bookings for services such as travel and accommodation [6]. For a shop whose repair bench runs on web bookings, the true share is much higher.

Who does not need paid website monitoring?

A business whose website is a brochure, with no bookings, orders or forms that matter, may be fine with a free uptime pinger. If nothing is lost while the site is down except a few people reading your hours, an email when the home page stops answering covers the real risk.

The same goes for a business whose web person already monitors certificates and domains for them and answers the phone on weekends. Ask them directly how they would know if your certificate failed to renew on a Saturday, and who they would call. If the answer is specific, you may already be covered.

Paid monitoring earns its keep when the website takes money or appointments, when the domain, certificate and email are all separate things that can fail, and when the people who would notice are the customers. That describes most small businesses that sell or book online.

What should you do this week?

Find out when your website certificate and your domain expire, who gets the renewal notices, and who fixes them on a weekend. Write the answers down. Then set up at least one check on your booking or checkout page that alerts a phone, not just an inbox.

Start by opening your site in a browser and clicking the padlock to see the certificate's expiry date. Log in to your domain registrar and check the expiry date and the contact email on file; change it if it belongs to someone who has left. Ask your web person or host how certificates renew and what happens if the card on the account changes.

Then write a half-page plan: who is alerted, who fixes the site, what you tell customers, and where you post it. The Canadian Centre for Cyber Security's baseline controls for small organizations start with exactly this, a written incident response plan that names who handles an incident and how to reach the people outside the business who need to know [7]. A website that lapses on a long weekend is a small incident. Having the plan written means it stays small.