A competitor’s Android app quietly added “Contains ads” and a new $49.99 in-app tier. Slack had it the morning it went live.

Google Play listings change without much noise. A short description gets rewritten, the “In-app purchases” price range jumps, the Data safety section adds a new data type, “Contains ads” shows up on an app that never had ads. None of that needs a new version number, and Google only emails the developer who made the change. If it’s a competitor’s app, you hear about it from a user review or a prospect. (Example details below are for a made-up app called Example Notes. Competitor unnamed.)

So I watch the public listing page and send a two-line summary to Slack when the parts that matter move. Here’s the setup.

Which parts of the Play listing to watch

The listing URL looks like play.google.com/store/apps/details?id=com.example.notes. Add &hl=en&gl=US to the end. Play changes text and prices by language and country, and without those two parameters the watcher can see a different storefront on different days and alert on nothing.

Then decide which fields count:

• Short description. It’s capped at 80 characters, so every rewrite is deliberate. “Notes for students” becoming “Notes for teams” is a positioning change.
• Full description. Long and noisy, so I only care about new feature names, new plan names, and new industries.
• What’s new. Often the first public hint of the next pitch.
• The “Contains ads” and “In-app purchases” labels, plus the per-item price range in “About this app”. A range going from “$1.99 — $9.99” to “$1.99 — $49.99” usually means a new top tier.
• Data safety. New data collected or shared, or encryption and deletion claims changing. Privacy-minded buyers notice this one.

If they also ship on iOS, watch the App Store page separately. The fields aren’t the same, and one sentence for both pages gets messy.

Why “any change” is useless here

My first watch was just the URL with no instructions. It pinged almost every day. The rating count ticked up, the “Similar apps” row reshuffled, review snippets rotated, the download badge moved from one bucket to the next. Nothing worth reading.

What fixed it was one sentence:

Alert me when the short description, What’s new, “Contains ads” or “In-app purchases” labels, the in-app price range, or the Data safety section on this Google Play listing changes. Summarize in two sentences what moved, with the old and new wording when you can see both. Ignore ratings, review snippets, download counts, “Similar apps”, and layout changes.

If you only care about money, cut it down to the price range and the two labels. That’s the version I’d start with for a pricing-only watch.

Send it to one channel with an owner

We post these to #competitive-intel. Mobile-heavy teams use #android or #mobile. A typical alert reads:

Example Notes on Google Play: “Contains ads” label added. In-app purchase range changed from $1.99 — $9.99 to $1.99 — $49.99 per item. Link in thread.

Whoever owns competitive work that week replies with one word. “share” if sales or pricing should know today, “read” if it goes into the next battlecard update, “n/a” if it doesn’t touch us. Most alerts get “n/a”. The new $49.99 tier got “share” before lunch.

To be clear about scope. This watches a public Play Store page and summarizes what changed. It doesn’t log in to Play Console, track keyword rankings, pull revenue estimates, or read private data. A person still decides what it means.

Things I learned the hard way

• Pin hl and gl in the URL. This one change killed most of my false alerts.
• The price range is per item, not per plan. A new high end is a signal, not a receipt. Open the app if it matters.
• Data safety edits often land weeks before anyone writes about them.
• Watch three to five competitor apps, not twenty. Add more after the channel stays quiet for a month.
• Daily checks are plenty. Play listings don’t change hourly.

The tool

I run this on AyeWatch because I can paste the Play URL, describe what counts in a sentence, and get a short summary instead of a raw diff. There’s a Free Preview, and Pro is $9/month, which is where Slack delivery lives. Any page monitor that summarizes a change and posts to Slack would do the same job.

The point is timing. When a competitor adds a tier or flips on ads, your team hears it from Slack that morning, not from a prospect two weeks later.

Open-source licenses change more often than people expect, and they change in one file. Elastic moved Elasticsearch off Apache 2.0 in 2021. HashiCorp moved Terraform to the Business Source License in August 2023. Redis changed its license in March 2024. Each time, the edit landed in a LICENSE file and a blog post. Teams that depended on those projects mostly heard about it from Twitter, a vendor email, or legal asking why nobody flagged it.

The fix is boring. Watch the LICENSE file of the dependencies that matter, and post a two-line summary to Slack when it changes. Here’s how I set it up.

Which files to watch

Pick the projects where a license change would actually force a decision. For most teams that’s a short list. The database, the queue, the infra tool, the SDK you embed in a product you sell. Skip the 900 transitive packages.

For each one, save these public URLs:

• The LICENSE (or LICENSE.md, COPYING) file on the default branch, for example github.com/<owner>/<repo>/blob/main/LICENSE.
• The license section of the README, since some projects add “additional terms” there first.
• The project’s license FAQ or blog page, if it has one. That’s usually where the “why” shows up.
• The package registry page (npm, PyPI, crates.io). The license field there sometimes changes before anyone writes about it.

That’s it. No repo access, no scanner, no login.

Why release notes and dependency bots miss it

Dependabot and Renovate tell you a new version exists. They don’t read the license. A version bump PR that also flips Apache 2.0 to a source-available license looks exactly like every other bump.

Release notes are worse. A license change is a business decision, so it often ships in a blog post, not the changelog. And a full-repo watch is useless. The repo changes fifty times a day.

So I watch the file itself and tell the watcher what counts.

Alert me when this LICENSE file changes its license name, adds or removes usage restrictions, adds a field-of-use or competing-service clause, or changes the copyright holder. Summarize the change in two sentences in plain English. Ignore year bumps in the copyright line and whitespace or formatting edits.

The year-bump line matters. Lots of projects update “Copyright 2025” to “Copyright 2026” every January. You don’t want that in Slack.

Route it to one channel with an owner

We post these to #oss-licenses. A typical alert reads like this:

LICENSE changed for example-db. Apache 2.0 replaced with a source-available license that restricts offering the software as a managed service. Copyright holder unchanged. Link in thread.

One person owns the channel each month. They reply with one word. “ok” if it doesn’t affect how you use the project. “review” if legal or the platform lead should read it. “fork” if the team needs to look at a community fork or an older pinned version. Most alerts get “ok”. The one that gets “review” is the whole reason the channel exists.

To be clear about scope. This watches public URLs and summarizes what changed. It’s not a license compliance scanner, not an SBOM tool, not a FOSSA or Snyk replacement, and not legal advice. A person still reads the new license and makes the call.

Things I learned the hard way

• Watch the default branch. Some projects change main weeks before the next tagged release.
• Pin the exact file path. A repo that renames LICENSE to LICENSE.md should still trigger an alert, so watch the README license line too.
• Ignore copyright year bumps, or January becomes noise.
• Start with five to ten projects. Add more only after the channel stays quiet for a month.
• Keep your normal dependency review. The Slack alert is early warning, not the decision.

The tool

I run this on AyeWatch because I can point it at a public LICENSE URL, describe what counts in a sentence, and get a short summary instead of a raw diff. There’s a Free Preview, and Pro is $9/month, which is where Slack delivery lives. Any page monitor that summarizes a change and posts to Slack would do the same job.

The point is timing. When the next license change lands, someone on your team replies “review” the same day, not two weeks later when a customer asks.

We found out a SaaS vendor had swapped their audit date and added a new analytics subprocessor the hard way. Someone opened /trust during a renewal questionnaire and noticed the page no longer matched the screenshot in our vendor folder. Sales still said "SOC 2 Type II." The public trust center had quieter language and three new names on the subprocessors list. No email. No changelog. Just an edit on a public URL. (Example details. Vendor unnamed.)

The page had the change the day it went live. The problem wasn’t finding the URL. The problem was that nobody looked until renewal, and the alert (when there was one) went to one person’s inbox.

So now the trust centers we care about post into Slack. When subprocessors, cert badges, audit dates, report-request forms, or ISO/SOC wording move on a public /trust, /security, or /compliance page, a two-line summary lands in #vendor-risk with what changed. Here's the setup.

What to watch on a trust center

Start from the public URL your MSA, DPA, or security questionnaire already cites. Watch that page, not the homepage and not the blog.

• Subprocessors list. New names, removed names, or a region that suddenly includes a country you care about.
• Cert and badge language. SOC 2, ISO 27001, ISO 27701, PCI, FedRAMP. Badge present, badge gone, “Type II” becoming “in progress.”
• Audit and attestation dates. “Last audited” slipping a year without a banner is the quiet kind of drift.
• Report request form. The form that used to request the SOC report going 404, gated, or moved to a sales-only path.
• ISO/SOC body copy. Scope shrinks, exclusions grow, or “available on request” replaces a public summary.

Save the exact public URL. That is what you point a watcher at. No login to a vendor portal, no GRC questionnaire, no PDF that never updates.

Why vendor emails and annual review fail

Vendors rarely email you when they edit /trust. When they do, it is often a marketing note about a new certification, not a quiet subprocessor add. The annual security questionnaire is worse as a control. You check once a year. The page can drift for eleven months.

A full-page diff email fails for a different reason. Trust centers rewrite footer links, cookie banners, and marketing blurbs constantly. The inbox fills. People mute it. The one line about a new subprocessor gets lost next to a layout tweak.

Keyword alerts on the company name miss it too. Nobody publishes “we added a subprocessor” as a press release. The change lives on the trust URL and nowhere else.

What worked was one sentence that says what counts.

Alert me when this trust or security page adds or removes a subprocessor, changes SOC, ISO, or other certification language, moves an audit or attestation date, or changes the report request form or badge wording. Summarize what changed in two sentences. Ignore cookie banners, footer links, layout, and marketing blurbs that do not mention compliance, audit, or subprocessors.

If you only care about subprocessors and badges, tighten it.

Only alert for subprocessor list changes and for SOC or ISO badge or attestation wording. Skip everything else.

Route it to #vendor-risk with an owner reply

Alerts go where vendor risk already happens. We use #vendor-risk. A typical line looks like this.

Trust page changed for Acme Analytics. Three new subprocessors added under “Infrastructure,” including a new analytics vendor in EU. SOC 2 Type II badge still present. Link in thread.

Whoever owns vendor risk that week replies with one word. “review” if security or counsel needs to open the diff, “ok” if it is noise we already knew about, “escalate” if it would change a risk call. Most get “ok”. A new subprocessor on a tool that holds customer content gets “review” the same morning, before the next questionnaire cycle.

This is a watch on a public /trust, /security, or /compliance URL. It summarizes what changed and posts to Slack. It is not a GRC platform, not a questionnaire tool, not legal advice, and not a Vanta or Drata replacement. It does not claim pixel-perfect screenshot diffs. Someone still reads the page and decides.

Things I learned the hard way

• Watch the URL your contracts cite, not the pretty marketing trust page if those are different.
• Ask for the before/after in plain language. “Page changed” with no detail makes people ignore it.
• Ignore cookie and footer churn, or the channel fills with noise.
• Start with vendors that hold real customer data. Auth, CRM, support inbox, AI feature vendor, primary cloud. Skip the rest until the channel stays quiet.
• Keep the annual questionnaire. The Slack watch is early warning, not a replacement for reading the report.
• A badge disappearing still matters. So does a form that quietly stops accepting report requests. Both are easier to catch when the alert is in Slack, not in one inbox.

The tool

I run this on AyeWatch because I can point it at a public trust or security URL, describe what counts in plain English, and get a two-line summary instead of a raw page dump. There’s a Free Preview, and Pro is $9/month, which is where Slack delivery lives. Any page monitor that summarizes a change and posts to Slack would do.

The goal is simple. The next time a vendor edits their trust center, someone in #vendor-risk replies "review" while the change is still fresh, not eleven months later at renewal.

We missed a sources sought notice that was a near-perfect fit. NAICS 541512, a small business set-aside, a scope that read like our last two contracts. The SAM.gov saved-search email did arrive. It arrived in the inbox of a BD lead who was out that week, buried under forty other notices that matched the same code. By the time anyone read it, the response window had closed. (Example details. Agency and notice unnamed.)

SAM.gov had it the day it posted. The problem wasn’t finding it. The problem was that the alert went to one inbox, with no filter beyond the code.

So now new SAM.gov opportunities post into a Slack channel. When a notice matches our NAICS codes and actually fits what we do, a two-line summary lands in #bd-pipeline with the notice type, the set-aside, and the response date. Here's the setup.

What to watch on SAM.gov

Start from the Contract Opportunities search on SAM.gov and build the filter you’d use by hand. Then watch that search, not the homepage.

• NAICS codes. Two to four codes you actually win under. 541511 and 541512 for most IT services shops. More codes means more noise, not more wins.
• Notice type. Sources Sought and Presolicitation are where you get in early. Combined Synopsis/Solicitation and Solicitation are where the clock is already running. Award Notices tell you who beat you.
• Set-aside. Small Business, 8(a), SDVOSB, WOSB, HUBZone. Filter to the ones you qualify for.
• Keywords. A few words from your past performance, like “Salesforce,” “data migration,” or “FedRAMP.”
• Place of performance, if you can’t staff work everywhere.

Save the filtered results URL. That public search page is what you point a watcher at. No login to a contractor account, no bid portal.

Why the built-in saved-search email isn’t enough

SAM.gov lets you save a search and get email notifications. Use it. It’s free and it’s the official source. But it has three habits that cost us.

It goes to one person. If that person is traveling or heads-down on a proposal, the notice waits.

It matches on the filter, not on fit. A NAICS code covers a lot of ground. 541512 brings in everything from help desk staffing to large systems integration. Forty notices a week, three worth reading.

It doesn’t tell you what’s inside. The subject line names the notice. You still open each one to find out whether it’s a sources sought or a solicitation due Friday.

Keyword alerts on the open web are worse. Agencies don’t announce sources sought notices on social media. The notice lives on SAM.gov and nowhere else.

What worked was one sentence that says what counts as a fit.

Alert me when a new opportunity appears in this SAM.gov search that involves CRM implementation, data migration, or cloud application work. Include the notice type, set-aside, agency, and response date in two sentences. Ignore modifications that only change a date, and ignore notices for hardware, construction, or staffing-only contracts.

If you only want early-stage notices, tighten it.

Only alert for Sources Sought, RFI, and Presolicitation notices. Skip Award Notices and amendments.

Route it to #bd-pipeline with an owner reply

Alerts go where capture work already happens. We use #bd-pipeline. A typical line looks like this.

New SAM.gov notice: Sources Sought, small business set-aside, NAICS 541512. Agency wants a CRM data migration to a cloud platform. Responses due in 12 days. Link in thread.

Whoever owns capture that week replies with one word. “pursue” if we’ll draft a capability statement, “watch” if it’s interesting but early, “pass” if it doesn’t fit. Most get “pass”. A clean sources sought in our lane gets “pursue” the same morning, and the response goes out with a week to spare.

This is a watch on a public SAM.gov search page. It summarizes what’s new and posts to Slack. It is not a bid-writing tool, not a GovWin-style pipeline database, not a proposal manager, and it doesn’t submit anything. It isn’t legal or compliance advice either. Someone still reads the notice and decides.

Things I learned the hard way

• Sources sought responses are short and easy to miss. They’re also where agencies shape the set-aside. Catch these first.
• Ask for the response date in the summary. “New notice” with no date makes people defer it.
• Ignore amendments that only push a date, or the channel fills with repeats.
• Keep the NAICS list short. Every code you add because you “might” bid triples the noise.
• Keep the SAM.gov email on as a backup. The official notification is still the record.
• Developers can also pull notices from SAM.gov’s public opportunities API. That works if you want to build and maintain it yourself.

The tool

I run this on AyeWatch because I can point it at a public SAM.gov search, describe what counts as a fit in plain English, and get a two-line summary instead of forty raw matches. There’s a Free Preview, and Pro is $9/month, which is where Slack delivery lives. Any page monitor that summarizes a change and posts to Slack would do.

The goal is simple. The next time a sources sought notice lands under your NAICS code, someone in #bd-pipeline replies "pursue" while the response window is still wide open.

A competitor’s App Store listing still showed the same version number, so nobody checked it. The subtitle had changed from “Notes for teams” to “Enterprise notes for ops.” Promo text now named three industries we sell into. The Pro subscription line went from $7.99/month to $9.99/month. Sales heard the price from a prospect on a demo four days later. (Example details for a made-up app called Example Notes. Competitor unnamed.)

The public apps.apple.com page showed every line. We just weren’t watching that URL.

So now competitor listings post into Slack. When subtitle, promo text, What’s New, screenshot captions, privacy labels, or IAP and subscription price text on the page change, a short summary lands in #competitive-intel or #mobile. Here's the setup.

Which listing fields matter

Watch the public listing page, not the binary. Version bumps are noisy. The text and price lines are what prospects see.

• Subtitle. Positioning in fifteen words. “For teams” becoming “for Enterprise” is a signal.
• Promotional text. Apple lets this change without a new binary. Competitors rewrite it when they chase a segment.
• What’s New. Release notes often tip the next pitch before the marketing site updates.
• Screenshot captions. Caption copy moves when the product story moves.
• Privacy labels. New data types or tracking disclosures often show up here first.
• In-app purchase and subscription price text on the page. Not a commerce API. The dollar amounts and plan names printed on the listing.

For Example Notes, the URL looks like apps.apple.com/app/example-notes/id0000000000. Optionally add the Play Store listing if they ship Android. Public browser URLs only. No App Store Connect or Partner Center login.

Why App Store emails, keyword alerts, and screenshot tools fail

Apple emails the developer when their own listing changes. You are not that developer. You get nothing when a competitor rewrites their subtitle.

Keyword alerts for the app name fire on blogs, Reddit, and press. They miss a quiet listing edit that never leaves the store page.

Screenshot-diff and rank tools are a different job. Pixel comparisons scream when Apple restyles the chrome. Rank trackers track charts, not whether Pro went from $7.99 to $9.99. Review scrapers watch ratings, not pricing copy.

A plain “any change” watch is noise. Related apps reshuffle, “You Might Also Like” rotates, layout chrome shifts. My first try pinged nine times in a week. Two were real text or price edits.

What worked was one sentence that names the fields.

Alert me when the subtitle, promotional text, What’s New, screenshot captions, privacy labels, or in-app purchase / subscription price text on this App Store listing page changes. Summarize in two sentences what moved, with the old and new wording when you can see both. Ignore related apps, ratings count ticks, review snippets, “You Might Also Like,” footer links, and layout chrome.

If you only care about money and positioning, tighten it.

Only alert for subtitle, promotional text, and any price or plan name change in the in-app purchase or subscription section.

Route it to #competitive-intel or #mobile with an owner reply

Alerts go where mobile and competitive work already live. We use #competitive-intel. Product-led mobile teams often use #mobile. A typical line looks like this.

Example Notes App Store listing: subtitle changed from “Notes for teams” to “Enterprise notes for ops.” Pro subscription on the page now shows $9.99/month (was $7.99). Link in thread.

Whoever owns competitive or mobile that week replies with one word. “read” if they’ll open the listing and update the battlecard, “share” if sales needs the price or positioning note now, “n/a” if it doesn’t touch us. Most get “n/a”. A price move or an Enterprise subtitle gets “share” the same day.

This is a semantic watch on a public listing URL. Not App Store Connect, not a rank tracker, not a review inbox, not a screenshot-diff tool, not an IAP commerce bot. It does not log in. It summarizes the text and pricing fields that changed. Someone still decides what to do with it.

Things I learned the hard way

• Subtitle and promo text move without a version bump. Watching “new version” alone misses the rewrite.
• Ask for old and new wording in the summary. “The listing changed” sends someone hunting through screenshots.
• Price text on the public page can lag or vary by storefront. Treat it as a signal, not a receipt.
• Ignore rating count ticks or the channel becomes wallpaper.
• Daily is enough. Monthly is how sales hears the price first.
• Drop apps that stopped mattering.

The tool

I run this on AyeWatch because I can point it at a public apps.apple.com listing, say which fields matter in plain English, and get a short summary instead of a pixel diff of the related-apps row. There’s a Free Preview, and Pro is $9/month, which is where Slack delivery lives. Any page monitor that summarizes a change and posts to Slack would do.

The goal is simple. The next time a competitor flips their subtitle to Enterprise or moves an IAP price on the listing, someone in #competitive-intel replies "share" before a prospect mentions it on a call.

On a Friday demo call, a prospect read us a line from a competitor’s case study. A logistics customer said switching had cut their onboarding from six weeks to nine days. The prospect wanted to know if we could match that. Nobody on our side had seen the post. It went up on Tuesday. By Friday their sales team was sending it as a follow-up link, and it had come up in two of our other deals. The post also changed how they talked about the category. They stopped saying “workflow automation” and started saying “ops onboarding.” A few weeks later the same phrase was on their homepage. (Example details, competitor unnamed.)

None of it was hidden. The case study sat at the top of their public customers page with a title and a link. We just weren’t looking.

So now competitor blog and case study index pages post into Slack. When a new post or case study shows up on one of those list pages, a two-sentence summary with the title and link lands in #competitive-intel. Here's the setup.

Which competitor pages to watch

The index pages, not the posts. One list page tells you something new went out. You don’t need to watch every article.

• The blog index, usually /blog, /insights, or /articles
• The case studies or customers index, usually /customers, /case-studies, or /customer-stories
• The resources hub, often /resources, where guides, reports, and webinar pages show up
• A category or tag page if the blog is huge, like /blog/category/product, so you only see posts in your area

For a made-up competitor called Example Ops, that’s exampleops.com/blog, exampleops.com/customers, and exampleops.com/resources. Three competitors means about nine URLs, which covers most teams. Stick to pages anyone can open without logging in. If the case study itself sits behind a form, the index still shows the title, and the title is usually enough to know it matters.

Why RSS, newsletters, and “any change” fail for this

RSS works when it exists. Plenty of marketing sites don’t publish a feed anymore, and customer story pages almost never have one. The feed that does exist usually covers the blog and skips the case studies, which is the page sales actually needs. And a feed reader is one more tab nobody opens.

Competitor newsletters are slow. I signed up for three. One sent a monthly roundup, so posts reached us weeks late. The other two landed in a shared inbox nobody checked.

A plain “any change” watch on a blog index is noise. The popular posts widget reshuffles, author bios change, the newsletter signup box gets a new headline, and cookie banners swap. My first try pinged eleven times in a week. One of those was a new post.

What worked was one sentence that says what matters.

Alert me when a new blog post, case study, customer story, guide, or report appears on this page. Summarize in two sentences with the title, the customer or topic, and the URL of the new item. Ignore author bios, related or popular posts widgets, newsletter signup boxes, cookie banners, footer links, and layout changes.

For a busy blog, I narrow it.

Only alert for posts about onboarding, workflow automation, or comparisons with other tools, plus every new case study.

Route it to #competitive-intel or #marketing with an owner reply

Alerts go where positioning gets decided. For us that’s #competitive-intel. Smaller teams often use #marketing. A typical line looks like this.

Example Ops customers page: new case study “How Example Freight cut onboarding from six weeks to nine days.” Logistics customer, claims a 78% drop in setup time. Link in thread.

Whoever owns competitive positioning that week replies in the thread with one word. “read” if they’ll read it and update the battlecard, “share” if sales needs it now, “n/a” if it doesn’t touch us. Most alerts get “n/a”. A case study in a segment we sell to gets “share” and a note in the sales channel the same day.

This is not an RSS reader, a social listening tool, an SEO rank tracker, or a scraper that copies every post. It doesn’t log in, fill out gated forms, or read the full article. It watches a public index page and summarizes the new title and link that showed up. Reading the post is still a person’s job. This just makes sure a person knows it exists.

Things I learned the hard way

• Watch the case studies page first. Blog posts shape opinion. Case studies show up in deals.
• Ask for the title and URL in the summary. “The page changed” sends someone hunting.
• Some blogs keep a featured post pinned at the top. Tell the filter to ignore the featured slot or you’ll get the same post every time it rotates.
• Check where the index actually lives. Companies move blogs to a subdomain or a /hub path and leave the old page frozen.
• A daily check is enough. A weekly check is how you hear about it from a prospect.
• Drop competitors who stopped mattering. A channel full of “n/a” gets muted.

The tool

I run this on AyeWatch because I can point it at a public blog or case study index, say in plain English what counts as new, and get the title and link instead of a diff of the sidebar. There’s a Free Preview, and Pro is $9/month, which is where Slack delivery lives. Any page monitor that can summarize a change and post to Slack would do the job.

The goal is simple. The next time a competitor publishes a case study in your category, someone in #competitive-intel replies "share" before a prospect reads it to you on a call.

Our AI bill doubled in a month and nobody had shipped anything new. We run a nightly job that summarizes support tickets with a mid-tier model. The vendor’s pricing page had added one row. Prompts over 200K tokens now billed at $6 per million input tokens instead of $3. Our job stuffed whole ticket histories into one prompt, so most calls crossed the line. The invoice came in at $1,840 instead of the usual $910 (example numbers). Two weeks after the price change, the same vendor’s models page gave the snapshot we had pinned a retirement date. We heard about that one from model_not_found errors the day it hit.

Both changes were public. Both sat on pages nobody had open. So now those pages post into Slack. When an AI vendor’s pricing or model page changes a rate, a free tier, a context window, a rate limit, or a model’s status, a two-sentence summary lands in #ai-ops with the link. Here's the setup.

Which AI vendor pages to watch

Only the vendors you actually call, and only two kinds of page per vendor. The price list and the model list.

• OpenAI: developers.openai.com/api/docs/pricing, developers.openai.com/api/docs/models, and developers.openai.com/api/docs/deprecations
• Anthropic: claude.com/pricing, platform.claude.com/docs/en/about-claude/pricing, and platform.claude.com/docs/en/models/overview
• Google: ai.google.dev/gemini-api/docs/pricing and ai.google.dev/gemini-api/docs/models
• Azure OpenAI: azure.microsoft.com/en-us/pricing/details/azure-openai/
• AWS Bedrock: aws.amazon.com/bedrock/pricing/

If you only use one model family on Bedrock, the Bedrock page plus that vendor’s own model page is enough. Most teams end up with six to ten URLs.

Why RSS, newsletters, and “any change” fail for this

Vendor blogs announce new models loudly and price increases quietly. A long-context surcharge or a free tier cut usually shows up as a table edit, not a post. RSS never sees it.

Newsletters are a week late and cover every vendor you don’t use. I read one, skimmed the rest, and still missed the row that mattered to us.

A plain “any change” watch on a pricing page is noise. These pages rotate hero banners, swap blog cards in the sidebar, and change login prompts. I muted my first attempt in four days.

What worked was one sentence that says what matters.

Alert me when this page changes a price, a rate per million tokens, a free tier or credit, a context window, a rate limit, or a model’s name, availability, deprecation, or retirement date. Summarize in two sentences with the model name, the old and new value, and the URL. Ignore marketing banners, blog and news sidebars, login or sign-up prompts, and layout changes.

For a big pricing page with dozens of models, I narrow it.

Only alert for the models we use, gpt-example-mini and claude-example-sonnet, plus any change to batch or cached input pricing.

Route it to #ai-ops or #ml with an owner reply

Alerts go where model choices get made. For us that’s #ai-ops. Teams with a separate ML group often use #ml. A typical line looks like this.

Example vendor pricing page: input price for example-model-mid on prompts over 200K tokens changed from $3.00 to $6.00 per 1M tokens. Under 200K is unchanged. Link in thread.

Whoever owns the feature that calls that model replies in the thread with one word. “pin” if we hold the current model or snapshot while someone checks cost, “ack” if it affects us and a change is coming, “n/a” if it doesn’t. Most alerts get “n/a”. A retirement date gets a ticket the same day.

This is not a billing dashboard, an invoice parser, a cost calculator, an LLM router, or a usage tracker. It never logs into your vendor console and it doesn’t know what you spend. It summarizes text the vendor already published on a public pricing or model page. Keep your real cost monitoring. This just tells a person that the price list moved.

Things I learned the hard way

• Watch the model list, not only the price list. Retirements break clients faster than price changes break budgets.
• Ask for the exact model name in the summary. “A model was deprecated” is useless when a vendor lists forty.
• Long-context and cached-input rows change more often than headline prices. Name them in the filter.
• Cloud resellers lag. Azure and Bedrock often update days after the vendor’s own page, so watch both if you buy through one.
• A daily check is enough. A weekly check is how you hear about it from finance.
• Prune the list when you drop a vendor. Dead watches are how the channel gets muted.

The tool

I run this on AyeWatch because I can point it at a public pricing or model page, say in plain English which changes matter, and get a two-sentence summary instead of a diff of the hero banner. There’s a Free Preview, and Pro is $9/month, which is where Slack delivery lives. Any page monitor that can summarize a change and post to Slack would do the job.

The goal is simple. The next time an AI vendor changes a rate or retires a model, someone in #ai-ops replies "pin" before the invoice or the error log tells you.

The version bump that bit us wasn’t a security issue and it wasn’t a major release. An HTTP client we wrap shipped 4.2.0 on a Tuesday. The README on its npm page said, in one line near the top, that the default request timeout had dropped from 30 seconds to 10. Our main app had a lockfile and stayed on 4.1.3. A small payments worker didn’t. Its Dockerfile ran a plain install against ^4.1.0, so Thursday's image build pulled 4.2.0 and slow bank calls started failing. The package page had been telling us for two days.

So the handful of packages that can actually break us now post into Slack. When a new version shows up on the public registry page, a two-sentence summary lands in #deps with the old version, the new one, and anything the page says about breaking changes, dropped runtimes, or changed defaults. Here's how it's set up.

Which package pages to watch

Not every dependency in the lockfile. The few your code leans on hard.

Common shapes:

• npmjs.com/package/<name> for JavaScript and TypeScript packages (npmjs.com/package/axios, npmjs.com/package/@scope/sdk)
• pypi.org/project/<name> for Python packages (pypi.org/project/requests, pypi.org/project/pydantic)
• pypi.org/project/<name>/#history when you want the release list rather than the README
• Optionally the project’s own changelog page, when the registry README is thin and the real notes live elsewhere

I pick vendor SDKs, the HTTP client, the ORM, the auth library, and anything we’ve been burned by before. If a new version wouldn’t change how our code behaves, it doesn’t get a watch.

Keep the list short. Eight to fifteen packages is plenty for most teams. Add one when a package ends up in a critical path. Drop it when you remove the dependency.

Why Dependabot, RSS, and “any change” fail for this

We already had Dependabot. It opened a PR for 4.2.0, which sat in a pile of forty other bump PRs, mostly patch releases of dev tooling. Nobody reads a bump PR title closely enough to spot a changed default. It also only covered the repos where someone had set it up, and the worker wasn’t one of them. I still want Dependabot. It just isn’t a way to tell a person “this one matters.”

PyPI has a per-project releases RSS feed, and I piped a few into #eng. Each item was a version number and a date. No hint whether it was a typo fix or a new default, and npm has no official equivalent. The channel was muted inside a week.

A generic “any change” watch on the npm page was worse. The weekly downloads counter changes every time you look, and so do badges, sponsor blocks, and the “last publish” relative time.

What worked was a sentence about the version, not a diff of the page.

Alert me when this package page shows a new latest version. Summarize in two sentences the old and new version and any breaking change, deprecation, dropped Node or Python version, or changed default mentioned on the page. Include the URL. Ignore weekly download counts, badges, sponsor sections, “last publish” times, and README edits that don’t come with a new version.

For a package that ships patches every few days, I narrow it.

Only alert for a new major or minor version. Skip patch releases unless the page mentions breaking, removed, or changed defaults.

That filter keeps #deps readable. A download count tick stays quiet. A new default timeout does not.

Route it to #deps or #eng with an owner reply

Alerts go where people already ask “did something update?” For us that’s #deps. Smaller teams often use #eng. A typical line looks like this.

acme-http-client (npm): 4.1.3 to 4.2.0. README says the default request timeout changed from 30s to 10s and Node 16 is no longer supported. Link in thread.

Whoever owns the code that uses that package replies in the thread with one word. “pin” if we need to hold the version until someone looks, “ack” if it affects us and a PR is coming, “n/a” if it doesn’t. Most alerts get “n/a”. When it’s “pin”, that thread is where whoever touches the Dockerfile or requirements file checks first. The point is that the answer shows up before the next image build, not after the first failed job.

This is not a vulnerability scanner, an SCA tool, or an SBOM generator. It doesn’t read your lockfile, open upgrade PRs, mirror a private registry, or replace Dependabot or Renovate. It summarizes text that maintainers already published on a public npmjs.com or pypi.org page. Keep your bump bot and your security tooling. This just gets the one release that changes behavior in front of a person.

Things I learned the hard way

• Watch the packages your runtime depends on, not your dev tooling. Linter bumps don’t need a Slack line.
• Lockfiles protect the services that have them. The alert is for the ones that quietly don’t.
• Ask for dropped runtime support by name. “No longer supports Python 3.8” breaks a build as surely as an API change.
• Scoped and renamed packages need the exact registry URL. A watch on the old name goes silent when the project moves.
• A daily check is enough. Most teams don’t rebuild images faster than that, and a weekly check is how you find out from a failed job.
• Review the list when the manifest changes. Removed packages left on the list are how the channel gets muted again.

The tool

I run this on AyeWatch because I can point it at a public npm or PyPI package page, say in plain English which version changes matter, and get a two-sentence summary instead of a diff of the download counter. There’s a Free Preview, and Pro is $9/month, which is where Slack delivery lives. Any page monitor that can summarize a change and post to Slack would do the job.

The goal is boring. The next time a package you depend on ships a version that changes a default, someone in #deps should reply "pin" before the next build pulls it in.

The last docs rewrite that bit us showed up as a support ticket, not a changelog. Our client kept posting to an endpoint that still looked fine in memory. The public reference page had already dropped the old path, marked a field required, and pointed everyone at a new URL. The page still said the API was “stable.” We found out when responses started coming back 410 and someone opened a ticket asking why checkout was broken.

So the docs pages we actually call now post into Slack. When a required param shows up, an auth scheme changes, an endpoint gets renamed or removed, a response field disappears, or the version guidance flips, a two-sentence summary lands in #api-changes with the URL. Here's how it's set up.

Which docs pages to watch

Not the whole docs site. Not the changelog RSS. The specific endpoint or reference URL your code hits.

Common shapes:

• docs.vendor.com/api/... for the endpoint you call (docs.stripe.com/api/charges, docs.github.com/en/rest/...)
• vendor.com/docs/api/... when docs live under the main domain
• api.vendor.com/docs/... or developers.vendor.com/... for API-first vendors
• A single reference page per integration you own, not the docs homepage

I watch the pages for auth, the endpoints in our critical paths, and any page that lists required request fields or response schemas we parse. If a page rewrite wouldn’t force a code change, it doesn’t get a watch.

Keep the list short. Six to ten URLs is enough for most teams. Add a watch the week you ship a new integration. Drop it when you rip the vendor out.

Why “any change” and changelog RSS fail

My first version was a generic watch on the docs root, plus the vendor’s changelog feed into #eng. It fired for sidebar renames, "last updated" stamps, typo fixes, unrelated endpoints two sections down, and blog-style release notes about features we don't use. Within a week the channel was muted. The rewrite that mattered sat between a nav reorder and a footnote edit.

A plain HTML diff is worse. Docs sites rewrite layout, TOC, and related-links widgets constantly. Every one of those is a change.

What worked was a sentence about the contract, not a diff of the page.

Alert me when this API docs page changes required request parameters, auth or permission requirements, endpoint paths, response fields we might parse, or version / stability guidance. Summarize what changed in two sentences and include the URL. Ignore navigation, sidebar, table of contents, “last updated” stamps, typo fixes, and edits that only mention unrelated endpoints.

For a fat reference page that covers twenty methods, I narrow it.

Only alert for the Create Charge and Refund sections. Ignore changes that only touch List or Webhook endpoints.

That filter is what keeps #api-changes readable. Nav noise stays quiet. A new required field does not.

Route it to #eng or #api-changes with an owner reply

Alerts go where people already ask “did their API change?” For us that’s #api-changes. Smaller teams often use #eng. A typical line looks like this.

Acme Payments docs: Create Charge now requires idempotency_key. Old path /v1/charges marked removed; use /v2/charges. Auth header scheme unchanged. Link in thread.

Whoever owns that integration replies in the thread with one word. “ack” if it touches our client and they’re opening a PR, “n/a” if it’s an endpoint or field we don’t use, “watching” if it’s unclear yet. When it’s “ack”, the same thread becomes the place support and QA check before blaming our code. Most alerts get “n/a”. The point is that the “docs moved under us” answer shows up before the 4xx spike, or at least before the next support ticket.

This is not an OpenAPI diff tool and not a contract test suite. It doesn’t pull a schema, run your SDK against a mock, or rewrite client code. It summarizes text the vendor already published on a public docs URL. Keep your contract tests and your changelog email. This just gets the rewrite into the right channel before someone learns it from a 410.

Things I learned the hard way

• Watch the endpoint page, not the docs homepage. The homepage rarely carries the param that will break you.
• Name the sections or methods in the sentence. A mega reference page will fire for endpoints you’ve never called.
• Ignore “last updated” and TOC. Those move for reasons that have nothing to do with your client.
• Deprecation banners matter, but so do silent rewrites: new required fields, renamed paths, removed response keys, auth scheme swaps. Watch for all of them, not only the word “deprecated.”
• Check on a daily cadence is usually enough. Docs rewrites are slower than status incidents. A weekly check is how you find out from a ticket.
• Review the URL list when you add or drop an integration. Stale watches are how channels get muted again.

The tool

I run this on AyeWatch because I can point it at a public API docs URL, describe which contract changes matter in plain English, and get a two-sentence summary instead of a diff of the sidebar. There’s a Free Preview, and Pro is $9/month, which is where Slack delivery lives. Any page monitor that can summarize a change and post to Slack would do the job.

The goal is boring. The next time a vendor rewrites the reference page you depend on, someone in #api-changes should reply "ack" before your client starts returning 410.

The last payments incident that hit us was on the vendor’s status page at 10:02. Our team heard about it at 10:21, from a screenshot of a tweet pasted into #eng. In between, support had three angry tickets and two engineers were reading our own logs trying to figure out what they broke. They broke nothing. The vendor had already written "Investigating elevated API errors" on a public page nobody had open.

So the status pages we depend on now post into Slack. When a vendor opens a new incident, moves it to identified or monitoring, or marks a component we use as degraded or major outage, a two-sentence summary lands in #incidents with the URL. Here's how it's set up.

Which status pages to watch

Only vendors that can take a customer-facing flow down. For most teams that list is short: payments, auth, email delivery, DNS and CDN, the primary cloud, source control and CI, and any AI API sitting in a product path.

Most of them publish on a predictable URL. Common shapes:

• status.vendor.com, the most common pattern (status.stripe.com, status.openai.com, status.twilio.com)
• vendorstatus.com for a few big ones (www.githubstatus.com, www.cloudflarestatus.com)
• vendor.statuspage.io when a smaller vendor runs on Atlassian Statuspage without a custom domain
• vendor.com/status when the page lives inside the main site

If you can’t find it, check the footer of the vendor’s docs site or search “vendor status”. Watch the status page itself, not the vendor’s blog or X account. The status page is where the words “Investigating” and “Major outage” show up first, and it’s the text your team will quote anyway.

I keep it to eight or nine vendors. If a vendor has an outage and nobody on the team would change what they’re doing, it doesn’t get a watch.

Why “any change” and RSS fail

My first version was the Statuspage RSS feed piped into a Slack channel. Every vendor, every post. It fired for scheduled maintenance windows weeks out, for “Resolved” posts on regions we don’t use, and for maintenance reminders that said the same thing as yesterday. Within a week people had muted the channel. The one post that mattered sat between a database maintenance notice and a resolved SMS delay in Australia.

A generic “alert me when this page changes” watch is worse. Status pages redraw uptime bars, rotate “last updated” timestamps and reorder past incidents constantly. Every one of those is a change.

What worked was a sentence about incidents, not a diff of the page.

Alert me when this status page reports a new incident, moves an incident to investigating, identified or monitoring, or marks a major component as degraded performance, partial outage or major outage. Summarize the incident title and current status in two sentences. Ignore scheduled maintenance posts that stay on schedule, uptime bar and history updates, footer edits and layout changes.

For a big vendor with dozens of components, I narrow it to the ones we touch.

Only alert for the API, Card Payments and Webhooks components. Ignore incidents that only mention other products or regions outside US and EU.

That filter is what keeps #incidents readable. Maintenance stays quiet. Investigating does not.

Route it to #incidents with an owner reply

Alerts go to the channel where people already ask “is it us or them?” For us that’s #incidents. Smaller teams often use #ops or #eng-alerts. A typical line looks like this.

Acme Payments status page: new incident “Elevated API error rates”, status Investigating. Card Payments component marked Degraded performance. Link in thread.

Whoever owns that vendor replies in the thread with one word. “ack” if it touches us and they’re on it, “n/a” if it’s a product or region we don’t use, “watching” if it’s unclear yet. When it’s “ack”, the same thread becomes the place support checks before replying to customers. Most alerts get “n/a”. The point is that the “it’s them, not us” answer shows up in minutes, where the people debugging can see it.

This is not uptime monitoring and not incident management. It doesn’t ping your endpoints, page anyone at 3am, or calculate SLA credits. It summarizes text the vendor already published. Keep your own synthetic checks and your on-call tool. This just gets the vendor’s own words into the right channel before the tweet does.

Things I learned the hard way

• Watch the status subdomain, not the marketing site. status.vendor.com is the page that changes during an outage. The homepage never does.
• Name components in the sentence. A vendor with 40 components will open incidents every week for products you’ve never used.
• Leave scheduled maintenance out unless it slips. A maintenance window that runs over is worth a line. One that starts and ends on time is not.
• Check often. Incidents move in minutes, not days, so this is the one watch where a slow check interval costs you.
• Status pages lag reality. Vendors post after they confirm, sometimes 10 to 20 minutes in. This won’t beat your own error alerts. It beats the “is it us?” thread.
• Review the vendor list every quarter. Add a watch the week a new vendor goes into a checkout or login path. Drop it when you rip them out.

The tool

I run this on AyeWatch because I can point it at a public status page, describe which incidents and components matter in plain English, and get a two-sentence summary instead of a diff of uptime bars. There’s a Free Preview, and Pro is $9/month, which is where Slack delivery lives. Any page monitor that can summarize a change and post to Slack would do the job.

The goal is boring. The next time a vendor writes “Investigating” on their status page, someone in #incidents should reply "ack" before anyone pastes a screenshot from Twitter.