How to monitor a SaaS marketing site, app, and docs together

The short answer

Add a separate tile for each public host you operate: the marketing site, the application, the documentation, and a status page if it is yours. Health-check the URL a stranger can open. Send visitor or revenue stats only from the hosts that can report them. When something fails, the tile name tells you which piece failed. A single tile pointed at the homepage will stay green while the app is down, which is the outage your customers actually feel.

DashCanopy does not host those properties and does not replace the provider consoles where you deploy them. It is the list that shows whether each one answered, in one place, on the interval for your plan.

Why these sites fail separately

The marketing site is often a static host or a site builder. The app is often another platform, with its own deploy and its own environment variables. The docs are often a third project that nobody deploys in the same pull request. A status page may be a fourth vendor. They share a brand and a customer. They do not share a process table. Monitoring them as one URL monitors only the URL you typed.

Picture a Tuesday when the docs search breaks and the marketing homepage is fine. If your only check is the homepage, the morning pass stays green and you hear about docs from a support ticket. A tile named for the docs host goes offline or degraded on its own, and the homepage tile stays online. That split is the result you are buying with a few extra sites on the plan cap.

The same split matters in the other direction. An app can be up while the marketing site’s DNS expires. Trials and sales stop, existing customers keep working, and a single “product” light would force you to guess which half broke.

What to add, and which URL to use

Marketing site: the canonical homepage. If the host redirects www to the apex, monitor the URL you tell the world to use.

Application: a URL that answers without a customer-specific session if you can offer one. A login page that returns successfully is a reasonable check that the app host is there. It does not prove that a logged-in workflow works. Be honest about that limit in the site description so future you does not read “online” as “checkout works.” If you have a public health route that does not expose private data, that URL is usually a better check than the login page, because it is built to be requested.

Docs: the docs home or a known page that is generated with the docs deploy. A docs site that 404s its homepage and 200s a cached asset will lie to you if you monitor the asset. Open the URL in a private window and confirm you see documentation, not an error wrapped in your theme.

Status page: add it if you operate it and you want to know when the status page itself is down. A status page that is offline cannot carry the incident note you hoped to publish. Do not point the status-page tile at the app and pretend they are the same check.

Skip preview URLs, pull-request deploys, and local hosts. They change every day and will train you to ignore red tiles. Production hosts only, unless a long-lived staging environment is something you have decided to watch on purpose.

Adding each one is the same flow: name, URL, optional description, then read the first check. The steps are in add a site and read the first health check.

Stats worth sending, and stats to leave off

The marketing site can report visitors if you install a snippet or endpoint. That number helps the weekly review. It does not tell you the app is healthy.

The app can report an aggregate you actually have, such as a visitor count on a marketing-facing app URL, or revenue if you send it from the billing source you connected. Do not push a customer list. The tile wants counts. Revenue in cents, if you send revenue, should match the field the API expects so the figure is not off by a hundred.

Docs can report visitors and usually should not report revenue. A docs tile with visitors and empty revenue is correct. Content cadence fields matter more on a publication than on docs, unless you publish docs as posts and want the last-post date.

The status page often needs no stats at all. Health is the point.

Webhooks, on Pro and Agency, fit the app better than the brochure site: signup events, failed jobs, billing events you already emit. Keep them beside the checks, not instead of the checks, as webhook events next to uptime explains.

How the plan cap shows up in a SaaS portfolio

Count hosts, not “products.” One product with a marketing site, an app, docs, and a status page is four sites. A second brand doubles that pattern. Starter’s cap is 5, which covers one product’s public hosts with a spare slot, and gets tight as soon as you add a blog or a second region’s marketing site. Pro’s cap is 15. Agency does not state a site cap and checks every minute, with up to 5 seats if more than one person should see the tiles.

A solo founder can run this list on Starter or Pro and read it in the morning check. A small company that wants several people in the dashboard is looking at Agency’s seat count, not at a shared password. Prices on the pricing page are Starter $19, Pro $69, and Agency $149 per month.

Check intervals matter more for the app than for a rarely changing docs site, but the interval is per plan, not per tile. You cannot check the app every minute and the marketing site every ten minutes on the same plan. Pick the interval the most urgent host needs.

When one of them fails

Read the tile name before you open a console. Docs offline and app online: open the docs host and the docs deploy. App offline and marketing online: open the app host, not the CMS. All of them offline at once: think DNS, the registrar, or a shared account, because independent hosts rarely die in the same minute for unrelated reasons. They can, if they were never independent and you put them on one account that just expired. The tiles still help, because “all red” is a different sentence from “docs red.”

Then tell customers in whatever status channel you already use. DashCanopy is not your status page. It is how you noticed which component to write about.

Questions about a SaaS portfolio

Should the API be its own tile?

Yes, if the API host is not the same URL as the app you already check. A separate API hostname can fail while the website login still loads. Monitor the public base URL or a health route that does not require a customer token and does not leak data.

Do I monitor the database?

Not as a public URL, unless you have a public health route that reports reachability without exposing the database. DashCanopy checks URLs it can request. A private database port is not a site tile. Use the host’s own checks for private infrastructure, and use DashCanopy for the public sites those systems support.

What about a blog on a subdomain?

Add it if you operate it and customers can open it. A blog is another host in the count. It belongs in the weekly stats review if it is part of how you reach people, and in the morning health pass either way.