Where webhook events belong next to uptime checks

The short answer

Keep health checks even after you turn on webhooks. A health check is DashCanopy asking your URL whether it will answer. A webhook is your site telling DashCanopy that something happened: an order, a signup, an error, or another event you chose to send. Pro and Agency include webhook event ingestion. Starter does not. Use the events to see activity. Use the check to see whether the site is up when the activity stops.

If you only have one of the two, choose the check. A site that cannot answer will not send a reliable event either. A site that answers and sends events is the pair a multi-site operator actually wants on the busy properties.

Two different questions

“Is the homepage up?” is a check. It runs on the plan interval whether or not a customer did anything. Starter runs it every 10 minutes, Pro every 5, Agency every minute. The result is online, degraded, or offline, as the tile status guide defines those words.

“Did an order just come in?” is an event. It happens when your store decides to notify you. No customers means no order events, and that silence is not an outage. A bug that swallows the webhook means no order events either, while the homepage still returns online. You can only tell those apart because you still have the check.

The pricing page lists webhook event ingestion as a Pro and Agency row, off on Starter. There is no public promise of an unlimited event archive or a specific retention period on that page. The landing FAQ says event retention and delivery depend on the plan, the integrations you connected, and the current configuration. Treat the feed as an operational inbox with those limits, not as a data warehouse. If you need a legal record of orders, that record lives in the store and the payment provider.

What to send, and what to leave out

Send events you would want on a tile or a feed during the day: a paid order, a new customer signup, a failed job you already alert on inside the app, a form submission if that form is the business. Name them in plain language in the payload you control, so the feed does not become a pile of internal codes only one developer understands.

Do not send every page view as a webhook. Page views belong in the visitor count, through the stats endpoint or the WordPress plugin, described in how stats land on a tile. A webhook per view will drown the orders you added webhooks to see. The dashboard’s visitor field is a counter. The event feed is a list. They solve different reading problems.

Do not use the webhook as the only monitor for “site is down.” When the site is down, it often cannot deliver the webhook that was supposed to say so. The check exists so a silent site still changes state. An event that says “health failed,” sent from the site itself, can be a useful extra. It is not a substitute for the external check.

Security belongs in the setup, not in an afterthought. A public URL that accepts events from anyone will fill your feed with junk or worse. Use the authentication your integration already documents, and do not paste signing secrets into a blog comment or a ticket screenshot. This article does not publish an event schema, because the fields depend on the integration you connected. Follow the API docs for the push your site actually makes, at API docs.

How to read the feed in the same morning as the tiles

During the morning check, read health first, stats second, events third.

Health offline: ignore the lack of new events. The site may not be able to send them. Fix reachability.

Health online, stats moving, events quiet on a store that usually sells before noon: look at the webhook connection before you assume demand disappeared. A disconnected notifier looks like a quiet day.

Health online, a burst of error events: the site is up and the application is unhappy. Open the app’s logs. The tile has done the sorting. It has told you this is not a host-down problem.

Health online, a normal trickle of orders: leave it. The feed is not a scoreboard you have to clear.

That sorting is the whole value. Without it, people open the payment dashboard to learn about an outage, or open the host to learn that nobody bought anything. Both detours feel like work. Neither is the right first tool.

Which plan, if webhooks are the reason

If you have four sites and you want order events in DashCanopy, Pro is the plan that includes ingestion, even though the site count would fit on Starter. Starter will still check health and show reported visitor and revenue stats. It will not take the event feed. Buying Pro only for webhooks is reasonable. Buying Pro and never pointing an event at it is a $69 monthly feature you are not using. The prices and the rest of the rows are in choosing a plan.

Agency includes the same ingestion, plus the REST API if you need to pull or automate from outside the dashboard. Do not step up to Agency only because you like the word webhook. Step up when the site cap, the seats, the API, or white-label is the actual requirement.

A small test before you depend on it

On a staging or low-risk site, send one known event and find it in the feed. Then stop the sender and confirm the tile can still go offline if you point the health check at a bad URL you control, such as a hostname you can change back. You are proving the two signals can disagree on purpose. When you have seen them disagree once, you will trust the sort on a real morning.

Put the production URL back on the health check as soon as the test is done. A test hostname left in the tile is a classic way to “monitor” a site you are not monitoring.

Limits

Webhooks arrive if the sender sends them and the network in between allows it. They can be delayed, duplicated, or dropped. Design the site’s own order record so a missed event does not lose a sale; the payment provider remains the system of record for money. DashCanopy is the place those notices can sit next to uptime, not the ledger.

This is not legal advice about what you must retain, and it is not a security audit of your endpoint. If the events include personal data, follow your own privacy obligations and send the minimum the feed needs.

Questions about webhooks and uptime

If I have webhooks, can I turn off health checks?

No. Leave the checks on. Events tell you what the site chose to report. Checks tell you whether it answered when DashCanopy asked. You want both on any site where silence could mean either “no customers” or “no server.”

Are webhooks included on Starter?

No. The pricing comparison lists webhook event ingestion on Pro and Agency only.

Can a webhook show revenue by itself?

An order event can tell you an order was reported. The revenue figure on the tile still comes from the stats you push, such as the WordPress plugin’s WooCommerce or Easy Digital Downloads totals, or a stats endpoint sending revenue in cents. Use the event as a line in the feed. Use the stat as the number on the tile. They should agree in direction. They are not required to be the same field.