Monitoring Now Delivers to Slack and Webhooks, Not Just Email

Two new delivery channels let a dataset Monitor post its change alert straight into a Slack channel or send a signed event to a webhook on your own systems. The trigger has not changed. A Monitor still speaks up only when a genuinely new pattern appears or an established one fades. What is new is where that alert can land.

What Is New

A Monitor re-runs the same validated statistical pipeline behind AI Insights on a schedule you set, and it reaches out only when the set of significant findings actually changes. Until now that alert arrived one way, by email. Monitors can now deliver the same alert through two additional channels: a message posted to a Slack channel, and a signed request sent to a webhook endpoint you control. Each Monitor can use one channel or several at once, and at least one channel has to stay enabled. Email remains the default, and nothing about the email alert changes.

The important part to understand first is what these channels do not touch. They change the destination of an alert, not the reason one is sent. Every check still runs the full testing pipeline, still corrects for multiple testing with the false discovery rate procedure, and still compares the current findings against the previous check. The first run of a Monitor establishes its baseline in silence. From then on, a Slack message or a webhook call goes out for the same reason an email would: a finding appeared that was not there before, or one that used to be present has faded for two consecutive checks. If nothing changed, every channel stays quiet.

Slack Notifications

Slack delivery uses a standard Slack Incoming Webhook. You create the webhook in Slack for the channel you want alerts to appear in, copy the URL it gives you, and paste it into the Monitor. When a check detects a change, the Monitor posts a message to that channel with the plain-language summary of what shifted, the same explanation the email alert carries, written for a reader who is not a statistician.

The value here is placement. A change in your data shows up where the responsible team already works, in the flow of conversation rather than in a separate inbox that someone has to remember to check. Whoever owns the number sees it in context and can pull in the right people in the same thread, within seconds of the alert arriving. For a team that lives in Slack, this is often the difference between acting on a shift the day it happens and noticing it a week later.

Webhook Notifications

A webhook turns a data change into an event your own software can act on. You give the Monitor an HTTPS endpoint, and when a check finds a change it sends that endpoint a monitor.finding event describing what appeared or disappeared. The request is signed with HMAC using a secret, so your receiver can verify that the call genuinely came from QuantumLayers before it acts on anything. You can supply your own secret, or let one be generated for you when you enable webhook delivery.

Two controls keep the stream clean and predictable:

Cooldown: a debounce window applied per finding and direction before the same finding can fire again, set to 60 minutes by default, so a result sitting at the edge of significance cannot flood your endpoint by flickering in and out.
Finding-type filter: an optional restriction that limits webhook delivery to the insight types you care about, for example only correlations or only trend breaks, so a downstream system receives just the changes it is built to handle. Leave it open and every finding type is delivered.

With those pieces in place, a Monitor becomes a trigger inside your own automation rather than a message a person has to read and relay. The webhook can open a ticket, page an on-call rotation, write a row to a database, update an internal dashboard, or kick off a downstream job. The statistical judgment about whether a change is real stays with QuantumLayers, and the decision about what to do next stays with your systems.

Setting It Up

Open the My Monitors section of your dashboard and create or edit a Monitor. Alongside the settings you already know, such as name, frequency, time, datasets and watched columns, you now choose which delivery channels are active. For Slack, paste the Incoming Webhook URL for the target channel. For a webhook, enter the HTTPS endpoint, then optionally set a signing secret, a cooldown, and a finding-type filter. If you leave the secret blank, one is generated for you. Email recipients continue to work exactly as before on any Monitor that keeps email enabled. Monitoring remains part of the Pro plan.

A Concrete Setup

Consider a Monitor on a connected e-commerce dataset that refreshes through the day. A setup that uses all three channels at once might look like this:

Monitor Name:     Checkout Funnel Watch
Check Frequency:  Daily, 08:00, America/Toronto
Delivery:         Email, Slack, Webhook
Email:            ops@company.com
Slack:            #data-alerts (Incoming Webhook URL)
Webhook:          https://hooks.company.com/ql/monitor
Cooldown:         60 minutes
Finding Types:    all, or restrict to correlations and trend breaks
Watched Columns:  sessions, add_to_cart, checkout_start, purchase

The first daily run sets the baseline quietly. Suppose that a week later a relationship develops between add-to-cart rate and checkout drop-off that was not there before. On the next check the pipeline detects it, it survives the false discovery rate correction, and because it was absent at the previous check it counts as a new finding. At that moment the alert reaches all three destinations together: an email lands in the ops inbox, a message appears in #data-alerts, and a signed monitor.finding event hits your endpoint, where it opens a ticket automatically. On any day where nothing new crosses the significance bar, none of the three fires.

Matching the Channel to Who Needs to Act

The three channels are not redundant. Each fits a different kind of recipient, and the point of allowing several at once is to route the same change to each of them in the form that suits how they respond:

Email is the durable record. It is the channel that reaches stakeholders who do not have a QuantumLayers account and who want the alert to sit in an inbox they can search later.
Slack is for shared awareness. It puts the change in front of a team in the place they already talk, where an alert can turn into a decision in the same thread.
Webhook is for machines. It lets a change trigger an action with no person in the loop, which is what you want when the correct response is a workflow rather than a conversation.

This is what it means, in practice, to stay on top of what is happening with your data. A shift in the numbers does not wait for someone to open a dashboard and go looking. The moment a check confirms the change is real, it can be logged for the record, surfaced to the team, and handed to your systems at the same time, each in the format that channel is best at.

Conclusion

Monitoring already answered the question that ad-hoc analysis and Scheduled Reports leave open: has anything changed since I last looked? Slack and webhook delivery decide where that answer goes. The rigor is unchanged, and so is the restraint that keeps a Monitor safe to leave running in the background. Point a Monitor at the dataset that matters, pick the channels that match who needs to respond, and a real change now reaches an inbox, a Slack channel, and your own software in the same moment, without anyone watching a screen to catch it.

This post is part of the QuantumLayers blog series on building analytics workflows that stay current. For the full picture of how Monitors detect change, see Introducing Monitoring. Monitoring is part of the Pro plan described on the pricing page. Set up your first Monitor at www.quantumlayers.com.