Besides reading Google’s data, SaaSMaestro can visit your websites itself to catch problems Google won’t tell you about. The checks are under Website health on Settings → your workspace → Data connections. Each is its own service, off until an owner or admin switches it on in its dialog, where they also choose which websites it covers. Nothing needs installing.
Checks come from our servers at 35.214.110.192. If your website is behind a firewall, Cloudflare or a security plugin, allowlist that address first. See Allowlisting our IP address.
The services
| Service | How often | What’s looked at |
|---|---|---|
| Uptime monitoring | Every 15 minutes | Whether the home page answers, confirmed from other regions before an outage is declared, plus daily Google tag, robots.txt, sitemap and page checks and a monthly report. |
| SSL certificate monitoring | Weekly | When the certificate expires and who issued it, and whether visitors actually get HTTPS. |
| Domain monitoring | Weekly | When the domain registration expires, the registrar, and registry holds. |
| DNS & email security | Daily | Nameserver and mail server changes, and the SPF, DMARC and DKIM records. |
| Blacklist & malware | Daily | Google’s Web Risk list of dangerous sites and abuse.ch’s URLhaus malware list. |
| Security headers | Weekly | Six common security headers, graded A to F, and files loaded over plain HTTP. |
| Lab performance | Weekly | A PageSpeed Insights test of the mobile home page, with its score over time. |
| Core Web Vitals | Daily | Real-visitor speed from the Chrome UX Report, read during Uptime monitoring’s daily checks once its API key is set. |
| Key page checks | Every 5, 15 or 60 minutes | Pages you choose, such as pricing or signup, must load and contain the text you give. |
| Heartbeat monitoring | As often as you set | Your own cron jobs, backups and workers request a private address; you’re alerted when one goes quiet. |
When a new website is added, you’re offered the services already switched on for the workspace. Warnings from SSL, domain, DNS, blacklist, security header and performance checks are emailed to owners and admins as “Critical issue alerts” as soon as a check finds them, each only once, and sent to any chat channel that takes them.
Uptime
Each website’s home page is checked every 15 minutes. A website only counts as down after two failed checks in a row, which avoids false alarms from a single slow response. Responses such as “unauthorised” or “too many requests” count as up, because the server is answering.
Before a second failure is declared an outage, servers in other regions load the website too. If most of them can, the problem lies between our main server and the website, such as a network fault or a firewall rule, so no outage is declared. The Uptime monitoring dialog lists the regions in use.
When a website goes down, owners and admins get a downtime email straight away (at most once per outage per week), and a critical issue is raised until it’s back. On the 1st of each month they also get a monthly uptime report with each website’s uptime and outages over the month before; anyone can turn it off for themselves under Notifications.
Daily checks
These run with Uptime monitoring, once a day for each website it covers.
| Check | What’s looked at |
|---|---|
| Google tag | Whether the home page carries this website’s GA4 tag, a different GA4 ID, Google Tag Manager, or nothing. |
| robots.txt | Whether it exists, whether it changed and whether it blocks every search engine. |
| Sitemap | How many URLs it lists, reading up to 10 child sitemaps. |
| Core Web Vitals | Real-visitor speed from the Chrome UX Report: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. Needs a Chrome UX Report API key, set in the Core Web Vitals box on the workspace’s Data connections tab. |
| Google index status | For websites linked to Search Console, whether each watched page is in Google’s index, from the URL Inspection API. |
| Internal links (weekly) | Up to 40 links to your own website from the watched pages are followed, and any that answer 404, 410 or a server error are listed. |
A website that loads its Google tag through a consent tool or Tag Manager may show “Google Tag Manager found” or “Not found” even though tracking works. Check GA4’s Realtime report to be sure.
SSL certificates
Once a week our servers read the certificate each website serves: when it expires and who issued it. Within eight days of expiry, or while HTTPS is missing, they look daily instead, so a renewal is noticed before anyone is warned. You’re warned a week before the certificate expires, again the day before, and once it has expired. It shows as an issue on the website’s page from 14 days before.
They also check that visitors get HTTPS: you’re warned when the website only answers over plain HTTP, or when plain HTTP serves the website without redirecting to HTTPS. Those warnings repeat weekly until fixed.
Domain registration
Once a week the registered domain (example.com for shop.example.com) is looked up with its registry through RDAP, or WHOIS where the registry has no RDAP. Within a month of expiry it’s looked up daily. You’re warned a month, a week and a day before the registration expires, and once it has. You’re also alerted straight away if the registry puts the domain on hold, which stops the website and email working, or if it has lapsed and is about to be deleted.
DNS and email security
Once a day the domain’s DNS records are looked up through DNS-over-HTTPS, so the results match what the rest of the internet sees. A change of nameservers or mail servers raises an alert straight away and stays on the website’s page for a week, because that’s what a hijacked domain or a botched migration looks like.
For domains that receive email, the check also flags a missing SPF record, more than one SPF record, an SPF record that lets anyone send (+all) and a missing DMARC record. DKIM can’t be listed, so it’s looked for weekly under the selectors common mail services use, and only shown when found.
Blacklists and malware
Once a day each website is looked up on Google’s Web Risk list, which makes Chrome and other browsers show visitors a red warning page instead of the website, and on abuse.ch’s URLhaus list of malware downloads. Either usually means the website has been hacked, and you’re alerted straight away.
This check needs a Google Web Risk API key, a URLhaus auth key or both, saved in its dialog. Without either it doesn’t run. Google’s free Safe Browsing API isn’t licensed for commercial use, which is why the paid Web Risk API is used.
Security headers and mixed content
Once a week the home page is loaded over HTTPS and graded on six headers: Strict-Transport-Security (HSTS), Content-Security-Policy, X-Content-Type-Options, X-Frame-Options (or CSP frame-ancestors), Referrer-Policy and Permissions-Policy. All six is an A, five a B, and so on. You’re told when HSTS is missing or fewer than four are sent.
The page is also searched for files loaded over plain HTTP. Scripts, styles and frames loaded that way are blocked by browsers and can break the page; images and media lose the padlock. Only the HTML as served is checked, so files added later by scripts aren’t seen.
Lab performance
Once a week Google’s PageSpeed Insights tests each mobile home page on a simulated phone and scores it out of 100, with its loading, blocking and layout shift timings. The last 12 weekly scores are kept. You’re told when the score is below 50, or falls by 15 points or more since the previous test, often before real visitors’ Core Web Vitals catch up. It uses the same Google API key as Core Web Vitals, with the PageSpeed Insights API turned on for its project. The test runs from Google’s servers, not ours.
Key page checks
Add the pages that matter most, such as pricing, signup or checkout, with the text each must contain, and choose to check every 5, 15 or 60 minutes. A page fails when it doesn’t load, answers with an error, or no longer contains the text, which catches a broken page that still answers “200 OK”. The text is looked for in the page as our server receives it, before any scripts run.
After two failures in a row, owners and admins get a downtime email, chat channels are told, and a critical issue is raised. They hear again when the page works.
Heartbeats
Each heartbeat gets a private address, such as https://saasmaestro.com/hooks/heartbeat/…. Have a job of yours request it every time it runs, for example by adding curl -fsS and the address to the end of a cron line. GET, POST and HEAD requests all count.
Choose how often a ping is expected, from every 5 minutes to once a week, and a grace period for jobs that run long. When no ping arrives within the interval plus the grace period, owners and admins get a downtime email, chat channels are told, and a critical issue is raised; they hear again when it pings. A heartbeat isn’t watched until its first ping arrives.
Watched pages and automatic notes
SaaSMaestro watches the home page and the five busiest landing pages. When a page’s status, title, meta description, robots directive or canonical address changes, or robots.txt changes, a timeline note is added automatically and marked “Detected automatically”. So is a page that drops out of Google’s index. That way an unexpected traffic change often comes with its explanation already on the chart.
Where to see it
Each service’s box on Data connections shows when it last ran and how many websites need attention, and its clock icon opens the recent results. Each website’s page has a Website health section with the latest results. Problems also appear as issues; see Issue checks and severities.