Uptime Monitoring for Small Business - What to Check First and Why

A small business rarely has an operations team, which means the person who notices the website is down is often a customer. This guide gives you an order of work: the handful of checks that protect the most revenue, how to send alerts to a person who can act, a runbook for the first fifteen minutes, and a list of things you can safely skip. You can set most of it up in an afternoon.

Think in journeys, not servers

Ask which pages or functions make you money or protect your reputation. The answer is usually shorter than expected:

• People finding you (homepage, key landing pages)
• People buying or booking (cart, checkout, booking form)
• People logging in (customer area, admin)
• Systems you depend on or expose (API, payment webhooks, email sending)
• Things that expire (SSL certificates, the domain name)

Monitor in roughly that order. A server graph showing healthy CPU tells you nothing if the checkout is returning errors.

What to monitor first

1. The homepage, with a keyword check

Set up an uptime monitor on your main URL. A bare status code check is not enough: a site can return 200 while displaying "Error establishing a database connection" or a hosting parking page. Add a keyword check for a phrase that only appears when the page is healthy, such as your business name in the footer or a product category.

2. The money path

Pick the page where a failure costs you directly: a booking form, a login, the cart or the checkout start. You cannot (and should not) complete a real purchase every minute, but you can monitor the page that loads the form and check for a keyword such as "Place order" or "Sign in". If your shop has a payment or webhook endpoint, monitor its health or a simple endpoint on the same application.

3. SSL certificate expiry

An expired certificate makes browsers show a full-page warning, which customers treat as "this site is unsafe." It is one of the most preventable outages. Use the SSL checker to see your current expiry, and set up expiry alerts well ahead of time. If you use automatic renewal, monitoring is how you notice it has silently stopped. See how to renew an SSL certificate and automate it और SSL/TLS certificate errors explained.

4. Domain expiry

If your domain lapses, your website and your email stop together. Registrars send reminders to a contact address that is often out of date. Use domain expiry watch so that an independent system warns you, and read domain expiry grace and redemption to understand what happens if the date passes.

5. DNS

A bad DNS edit or a provider problem takes everything offline in a way that looks like "the site is gone." Keep a reference of your important records (A/AAAA, CNAME, MX, TXT) and check them occasionally with the DNS checker. For a deeper background, see DNS explained for website owners.

6. Scheduled jobs

If you depend on nightly backups, invoice generation or order syncs, use a heartbeat monitor. Cron monitoring alerts when a job fails to check in. The backup is the first one to add: it is the job you only discover is broken when you need it. Details are in the cron heartbeat guide.

7. Email deliverability (periodically)

If you send order confirmations or booking emails, broken SPF or DKIM records can send them to spam without any visible error on your site. A monthly review is plenty; see the SPF, DKIM and DMARC guide.

A starter set

Seven monitors cover the great majority of what can seriously hurt a small business. For choosing intervals, read how often should you monitor a website.

Alert routing: who gets told

An alert nobody reads is not monitoring. Decide in advance:

• Primary contact. One named person responsible for acknowledging alerts during business hours. Not "the team": a person.
• Backup contact. Someone who is alerted if the primary does not respond within a set time, or who covers holidays and sick days.
• Channels. Email alone is slow and easy to miss. Add a second path that interrupts: a webhook into a chat channel, or an SMS or push notification via a service you trust. Alerts support email and webhook delivery, which can feed most chat and paging tools.
• Different severity, different path. A failed homepage goes to a phone. A certificate expiring in 14 days can go to email.
• Out-of-hours policy. Decide honestly whether you will respond at 3am. If not, route overnight alerts to be read in the morning rather than pretending someone is on call. An ignored 3am page trains people to ignore alerts.
• Shared mailbox risk. An alert sent to a general inbox that nobody owns gets lost. Use a personal address for the primary.

If a freelancer or agency maintains your site, agree in writing what they monitor, who they alert, and their response times.

A first-fifteen-minutes runbook

Print this and keep it somewhere you can find when the site is down.

1. Confirm. Is it really down, and for whom? Use a HTTP status checker or down from where to see whether it is global or local to you.
2. Say something. Post a short note on the status page, or on social media if you do not have one. "We know, we are working on it" is enough. See the status page guide.
3. Identify the layer. Work from outside in:
4. DNS wrong or missing? Check with the DNS checker.
5. Certificate expired? Check the SSL checker.
6. Server not responding? Look at your host's status page and dashboard.
7. Application error? Read the error message and your application's log. The guides on 500 errors, 502 errors, 503 errors और 504 errors walk through each.
8. Ask what changed. Most outages follow a change: a deploy, a plugin update, a DNS edit, a hosting plan change or an expiring certificate.
9. Roll back first, investigate later. If a recent change is the likely cause, reverting is usually faster than debugging live.
10. Call your host if you suspect infrastructure. Have the account number and support contact in your runbook, not in an email on the broken system.
11. Verify the fix from outside before announcing it.
12. Write it down. Even five lines: what happened, when, what fixed it. For serious incidents, use the postmortem guide.

The website health check and the outage root cause finder can speed up step 3.

Budget tools

You do not need an enterprise platform. A sensible combination:

• A free or low-cost external uptime service for the homepage and key pages (this site's uptime monitor is one option).
• Your hosting provider's built-in alerts for disk, memory and server availability.
• Free certificate and domain reminders that go to a shared, monitored address.
• A simple free status page rather than a custom build.

The principle is that external monitoring must be independent of the thing being monitored. A monitor running on the same server as your website goes down with it, saying nothing.

What not to over-monitor

More monitors can mean worse monitoring. Skip or defer:

• Every page on the site. Ten important pages are better than five hundred.
• Sub-minute intervals for a site where five minutes of downtime would not change your day.
• CPU and memory alerts with no action attached. If you would not act on it at 3am, it should not wake you.
• Duplicate monitors that all fail together for the same cause and generate a storm of alerts.
• Staging and test sites, unless someone depends on them.
• Vanity metrics. Performance scores matter, but they belong in a monthly review, not a pager.

Review your alerts monthly. Any alert that fired and led to no action should be tuned or removed, a point developed further in how to reduce false alerts in monitoring.

अगले कदम

• Set up your first monitor with the uptime monitor, then add domain expiry watch.
• Protect jobs using cron monitoring.
• Give customers visibility with a status page.
• Read why is my website down and keep it linked in your runbook.

सामान्य प्रश्न

What is the minimum monitoring a small business should have?

A keyword-checked monitor on the homepage, one on the page where customers pay or book, and expiry alerts for the SSL certificate and the domain. These four checks catch the most common causes of avoidable, visible outages.

Should I monitor from multiple locations?

If your customers are in several regions, or if you use a CDN, checks from more than one place help you separate a local network issue from a real outage. For a local business serving one city, a single reliable location is often sufficient as long as failures are confirmed before alerting.

Is email enough for alerts?

For low-urgency items such as certificate expiry weeks away, yes. For site-down alerts, add a channel that interrupts, such as a webhook into a chat app or a phone notification, because emails are easily missed.

Who should be on call in a business of two or three people?

One person is primary and another is a backup, with an agreed answer to "what happens at night and on holidays?" Write the policy down, even if it is "no overnight response, alerts are read at 8am."

How do I know my monitoring itself works?

Test it. Pause the site in a safe way or point a test monitor at a URL that returns an error, and confirm that the alert reaches the right person through each channel. Repeat the test after changing contacts or tools.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.