Website change alerts in Slack that nobody has to reopen the page for

Somewhere in your workspace there is a channel called #website-alerts, and at least three people have muted it. It fired eleven times last week. Ten of those were a rotating customer logo strip and a cookie banner that renders differently on Tuesdays. The eleventh was a competitor cutting their free trial from 14 days to 7, and nobody read it.

The obvious fix is to connect a page monitor to Slack so the team sees changes faster. That fix is what caused this. Speed is the easy half. A five-second alert that says "a page you watch changed" still costs someone a page load, a squint, and a lost train of thought. Gloria Mark's work at UC Irvine puts the average return-to-task time after an interruption at 23 minutes and 15 seconds. Twelve junk alerts a week into a five-person channel is not a notification problem. It's a payroll line.

So: connecting Slack takes two minutes, and we'll get it out of the way first. The rest of this is about what has to be inside the message.

Connect Slack first, in about two minutes

Slack's incoming webhooks are the whole mechanism. You create one in your Slack workspace, pick the channel it posts to, and Slack gives you a URL. In modsignal that URL goes into Settings → Notifications, and that's the integration.

Two things to know before you paste it anywhere:

• One webhook URL equals one channel. It is bound at creation. Routing to a second channel means a second webhook. That turns out to be useful, and we'll come back to it below.
• The URL is a credential. Anyone holding it can post into that channel as your app. Treat it the way you'd treat an API key, not the way you'd treat a Confluence link.

Channels in modsignal are per team and independent of each other. Email, Slack, signed webhooks and RSS all receive the same evidence, each best-effort, none blocking the others. If Slack is having an afternoon, your email alert still lands.

That's the part every vendor blog covers. Here's the part they skip.

Slack has opinions about your alert, and they're written down

Slack's API documentation constrains what a change alert can physically be, which is useful, because it means alert design is mostly an engineering problem with published answers.

• One message per second per channel. Slack tolerates short bursts and rate-limits sustained excess, returning HTTP 429 with a Retry-After header in seconds. Sustained violations can get an app disabled.
• 3,000 characters per Block Kit section text object, 150 for a header, 50 blocks per message.
• No file uploads through an incoming webhook. Slack's own docs say it plainly: images have to be referenced by URL.

Why a raw diff doesn't belong in Slack

Dump a unified diff of a long terms page into a section block and you'll pass 3,000 characters somewhere around the third changed paragraph. Slack doesn't truncate it for you. The API call fails, which is a real and reported failure mode, and the worst possible one: the change happened, the monitor caught it, and the channel stayed quiet.

So the diff lives on the monitor timeline, which is the source of truth. Slack gets the summary and the specific excerpt that changed. Channels are copies of the timeline, not replacements for it.

Why the screenshot is a link, not an attachment

On the browser agent tier we capture a full-page "page as checked" screenshot: the page as our Chromium instance actually saw it, after cookie banners were dismissed and the layout settled. It cannot travel through an incoming webhook as a file. Slack gets the pointer, one click from the message. That's not a design preference on our side, it's the documented behaviour of the transport.

Anatomy of a Slack website change notification you can forward

Here's the bar we hold ourselves to: you should be able to forward the alert into another channel, or paste it into a Linear ticket, and nobody has to reopen the page to decide what to do.

That looks like this:

Acme raised Pro seat pricing Pro moved from $12 to $15 per seat/month. Annual discount unchanged at 20%.

Before: "Pro — $12 per seat / month, billed monthly" After: "Pro — $15 per seat / month, billed monthly"

Confidence: 96% · Checked 09:15 UTC · View timeline →

Four elements. Each one is doing a job:

• One sentence of what changed. Not "a change was detected in the pricing section." The change, in words, at the top, because that's all most people will read and it's usually enough.
• Before and after excerpts. The actual text, both states. This is the part that makes the message forwardable. On the exact diff tier it's a unified diff instead, trimmed to the changed region.
• A confidence score. On the semantic and agent tiers, the model reports its own uncertainty and we surface it rather than hiding it. 96% and 71% deserve different reactions from you, and you can't have that reaction if the number isn't there.
• A link to the timeline. Full history, full diff, the screenshot on agent tier. One click, not an archaeology project.

Nothing in that message requires the reader to have context about the monitor, the tool, or the page.

Alert on the change, not on the page

The reason most #website-alerts channels get muted is that the monitor is answering the wrong question. "Did any bytes on this URL change?" is a question a pricing page will answer yes to several times a week, forever.

The question you want answered is the one you'd ask a colleague. So you write it that way: tell me when the price of any paid plan changes, or when a plan is added or removed. Ignore testimonials, logos and badge text. The semantic tier reads the fresh page against the last snapshot with that prompt and answers only whether the described change happened. Acme going from $12 to $15 fires. The trusted-by carousel rotating does not.

The cheap tier is still the right answer for a lot of pages. Byte-for-byte exact diff costs nothing, involves no model call, and is exactly what you want on a DPA, a subprocessor list, or a regulatory register, where every change matters and changes are rare.

Nobody A/B tests a DPA.

If you're not sure which tier a given page wants, we wrote a longer breakdown of how each check tier decides something changed, including where each one struggles.

Route by who acts, not by what the tool is

A single #website-alerts firehose is a mute waiting to happen, because there is no such thing as a person whose job is "website alerts."

Split by decision owner instead. A monitor in modsignal is one URL, one prompt, one tier, so this is a settings choice and not a project:

• Competitor pricing and positioning → #competitive. Product marketing acts on it, usually within a day.
• Subprocessor lists, DPAs, trust centres → #security. There's an objection window attached, and the subprocessor monitoring guide covers what to do inside it.
• API deprecations and changelogs → #eng. Different audience, different urgency, different time-to-action.

The pleasant side effect is that you stay well under Slack's one-message-per-second-per-channel ceiling without ever thinking about it. You've spread the traffic across channels that each get a handful of messages a week.

If you'd rather not own a webhook, use RSS

Slack ships a first-party RSS app. Type /feed subscribe [url] in any channel and Slack polls the feed itself, posting new items as they appear.

Every modsignal team gets an RSS 2.0 feed of its change events. The URL contains a secret token, so treat it like the webhook URL. Anyone with it can read your change history.

We'll recommend this route even though it uses none of our integration surface: for a read-only channel that a few people skim, RSS is less to configure and less to break, and the polling interval is Slack's problem rather than ours. Use the incoming webhook when you want alerts to land within seconds of the check.

When Slack is the wrong place for the alert

Three cases where we'd tell you to send it somewhere else.

First: compliance evidence that needs a trail. A Slack message is not an audit artifact. Point a signed webhook at your ticket system instead: JSON payloads with type of change_events or monitor_paused, plus run_completed heartbeats, each signed X-Modsignal-Signature: t=<unix>,v1=HMAC-SHA256 over t.body so you can verify it came from us. Then the change lands as a ticket with a timestamp and an owner.

Second: changes nobody acts on the same day. Job postings, hiring signals, slow-moving competitor content. Email is fine. It stacks, it's searchable, and it doesn't interrupt anyone.

Third: a channel that's already at capacity. If your team is already ignoring alerts, one more bot is not the fix. In incident.io's 2025 survey of DevOps and SRE teams, 67% of engineers admitted dismissing alerts without investigating. Fix the prompts first, then turn the channel on.

What this costs

Checks are never metered on any plan. You pay for reach: how many pages, how fast, how many teammates. All four notification channels are included everywhere, including Free.

• Free, $0. 3 monitors, daily checks, 2 team members, exact diff and semantic tiers, no credit card. Slack included.
• Pro, $25/mo. 25 monitors, checks every 15 minutes, 5 members, all three tiers.
• Scale, $49/mo. 100 monitors, every 5 minutes, 15 members.

For comparison, and to be fair about it: as of our last check in February 2026, Visualping's published pricing explainer put their Business tier at $100/month, bundling Slack and Microsoft Teams with shared workspaces and a 20,000-check monthly allowance. That's a coherent design for a product built around metered visual checks, and they're the biggest name in this category for good reason. Check their pricing page for current numbers, and we go through the philosophical differences on our Visualping alternative page.

The two-week test

Run this on whatever you're using now, including us.

Count the alerts your Slack channel received over two weeks. Then count how many of them required somebody to open the page to find out what happened.

If the second number isn't close to zero, the message is the problem, not the integration. Fix the prompt, fix the tier, split the channel. And if the channel is quiet for a week, that's the tool working. Silence means nothing you asked about happened.

Start on the free plan and point three monitors at pages you actually care about. Wire Slack in two minutes, then judge the messages.