Website monitoring

Your public website is often the first place customers check hours, services, contact details and credibility. When it is down, slow, showing certificate warnings or redirecting somewhere unexpected, trade suffers even if back-office systems are fine. Website monitoring in Business Vault watches observable public signals so an owner or office manager can notice problems early and delegate fixes.

What the check does. Supported website monitoring requests the public URL you record for the asset, follows a limited number of redirects, measures whether the site responds, notes if HTTPS is in use, reads certificate expiry dates, and inspects selected response headers that affect security posture at a high level. Results are stored over time so you can see when something changed.

What the check is not. Website monitoring is not a penetration test, malware scan, vulnerability assessment, web application firewall, or endpoint security product. It does not log into your CMS, crawl every page for defacement, or guarantee that code is free of flaws. Developers and hosting partners still patch applications, harden servers and run deeper tests where required.

Availability alerts tell you when customers cannot reach the site at all. That might be DNS, hosting, a expired certificate, or an upstream outage. Plain-English alert text explains what was observed; technical detail is available for whoever maintains the site.

HTTPS and certificate expiry matter because browsers warn visitors when certificates are invalid or near expiry. Monitoring flags upcoming expiry so renewal is not discovered by a customer screenshot on a Friday evening. It does not replace your host's renewal process or Let's Encrypt automation; it adds an independent reminder tied to your asset register.

Redirects are followed only up to a safe limit. Unexpected redirect chains sometimes indicate compromise or misconfiguration. When a check sees a change from previous observations, Business Vault can raise an alert so you compare with intended hosting settings.

Private and internal addresses are refused. The scanner is designed for public business sites, not for probing office networks or staging servers behind VPNs. Point monitoring at the customer-facing URL you want watched.

Monitoring works best alongside ownership records. Note the hosting provider, internal owner, agency contact and backup person on the website asset. When an alert fires, the right person gets the task without a chain of forwarded text messages.

Unknown means unknown. If a check has not run yet, status is not shown as healthy by default. Enable monitoring when the asset is added or after a migration so baselines reflect the current host.

Relationship to other Business Vault checks. Domain monitoring watches registrar and DNS context; email monitoring watches SPF, DKIM and DMARC for the mail domain. Website monitoring does not replace those. Together they cover common public failure modes small businesses feel first.

During an incident, attach monitoring history to the timeline. Providers and developers ask whether the site was up before changes. Historical results in Business Vault save debating memory.

Agencies managing many sites can monitor each client organisation separately. Alerts stay inside the client tenant so one site's certificate warning does not leak into another client's feed.

Website monitoring is operational notice, not a security certification. Use it to keep the public face of the business online and trustworthy, and use developers, hosts and specialist security services for code-level protection and testing.

Frequency and timing of checks follow your plan settings. A brief outage during maintenance may trigger an alert; note planned maintenance in the asset record so responders do not panic at expected downtime.

Mobile and desktop customers may see different results if redirects send phones elsewhere. Compare what monitoring sees at the public URL with what staff test on phones after changes.

Content delivery networks and caching can mask origin failures briefly. If alerts persist, ask your host whether edge caches are serving stale pages while origin is down.

Response headers monitored are chosen for practical signal, not exhaustive security analysis. Missing strict transport security or content security policy headers may appear as informational findings. Fixing them still belongs to your developer.

Uptime alone does not prove forms or checkout work. Functional testing of bookings and payments remains a manual or synthetic test outside basic HTTP monitoring. Record who runs those tests after site changes.

Seasonal businesses still benefit from monitoring between peaks. Certificate expiry during a quiet month hurts the first week of the busy season.

Link monitoring alerts to incidents when downtime exceeds a threshold you define internally. Business Vault gives the alert; your team decides when downtime becomes an incident with customer communications.

Historical uptime in Business Vault supports SLA conversations with hosts. It is not a legal record unless your contract says otherwise, but it beats anecdote when arguing about repeated outages.

Website rebuilds should trigger a monitoring baseline reset. After cutover, confirm the monitored URL matches the live customer URL, not a staging domain left in the asset by mistake.

Accessibility and performance matter to customers but fall outside basic uptime checks. Track them with separate tools if they are priorities; do not assume HTTP 200 means every user can complete a booking.

Third-party widgets for chat, maps or reviews can break while core HTML still loads. Staff should know how to disable a widget quickly if a supplier is compromised.

Monitoring from Business Vault runs from its infrastructure, giving an external view distinct from checking the site only from your office IP. Both views help when geo-blocking or ISP issues confuse diagnosis.

Document maintenance windows in the asset notes when your host notifies you. Correlating alerts with host status pages reduces duplicate tickets.

Large media files and slow hosts can time out checks occasionally. Investigate repeated failures rather than single blips. Compare with third-party uptime tools if disputes arise with your host.

Subpath monitoring is not the default: the check targets the URL you enter. If critical flows live on another hostname, add separate assets or accept that monitoring covers the entry point only.

SSL issuers and renewal methods vary. Some hosts auto-renew; others email the owner. Monitoring expiry is a backstop when auto-renew fails because card details expired.

When migrating hosts, run parallel monitoring on old and new URLs briefly if both remain public. Cut over alerts only after traffic moves permanently.

Defacement sometimes leaves HTTP 200 while content changes. Basic monitoring may not detect subtle text swaps. Pair monitoring with occasional manual page review or integrity tools your developer recommends.

Website monitoring complements human processes: opening the site on a phone after each deploy, checking forms after plugin updates, and confirming analytics still receive traffic. Automation and habit together catch more than either alone.

If your site serves multiple countries, remember monitoring reflects the URL checked from Business Vault infrastructure. Geo-specific blocks may require your developer to interpret alongside alert data.

E-commerce sites should note who receives payment gateway alerts separately from website uptime. Checkout can fail while the homepage loads, and the two problems follow different runbooks.

Static brochure sites and WordPress shops share the same monitoring basics but differ in who patches plugins. Name that owner on the website asset so alerts reach the person who can act.

Share alert notifications with your web host only after you confirm an issue is real. False escalations erode goodwill; documented monitoring history makes genuine escalations credible.

Website monitoring is one line on your risk register, not the whole register. Pair it with domain, email and profile ownership for a complete public-facing picture.

Owners who check the site manually each Monday still benefit from automated checks overnight and on public holidays when nobody is in the office.

Response time expectations belong in your internal runbook: who acknowledges an alert within one hour, who contacts the host within four hours, who decides on customer messaging.

TLS version and cipher details are for developers. Business Vault focuses on expiry and reachability so owners see problems without reading cipher suites.

Add the website monitoring URL to onboarding docs for new staff so they know which address customers use versus internal staging links.

Treat repeated website alerts as a signal to review hosting contract support levels, not only to restart the server once.

Document who receives monitoring emails and a mobile number for the hosting account holder so alerts are not trapped in a shared inbox nobody reads.

After DNS changes, allow propagation time before assuming monitoring failures mean the site is down globally.

Check provider status pages when alerts repeat without an obvious local cause.