How to Track Mentions of Your Open Source Project on Hacker News, Reddit, and X

A maintainer opens GitHub on a Tuesday morning and sees 300 new stars overnight. Nobody on the team posted anything. It takes twenty minutes of digging to find out why: someone linked the repo in a Hacker News comment, and a reply thread turned into a debate about whether the project is production-ready.

By then the debate is over. Two people said the docs were confusing, one person posted a workaround that's out of date, and nobody from the project answered.

I'm Julien, and I work on KWatch.io, a keyword monitoring tool for Hacker News, Reddit, X, Linkedin, Facebook, and Youtube. This post is for maintainers and developer relations teams who want to hear about those threads while they're still happening. I'll go through the keywords that work for code projects, where to send the alerts, and what the setup won't see.

Why GitHub stars don't tell you enough

GitHub tells you that something happened. A spike in stars, traffic, or clones says people found the repo, but it doesn't tell you where they came from or what they said about it.

The conversation that drives those numbers happens somewhere else. It's a Show HN post, a "what do you use for X?" thread in a subreddit, or a developer on X posting a benchmark. Those are also the places where a wrong claim about your project spreads fastest, because nobody's there to correct it.

So the goal is simple. Every time someone names your project in public, the right person on the team should see it within the hour, with a link to reply.

Pick keywords that fit code projects

Open source names are hard to monitor. A lot of them are ordinary words, animals, or short acronyms, and a plain alert on the name alone will drown you. The fix is to give each alert more than one way to be precise.

Start with the strings nobody types by accident. Your repo path (github.com/acme/widget), your package install command (npm install acme-widget or pip install acme-widget), and your docs domain are about as precise as keywords get. When people recommend a library, they paste one of these more often than you'd expect.

Then add the project name, paired with context. In KWatch, a comma between words means all of them must appear, so widget, rust only matches content that contains both. I'd write two or three pairs that cover how people talk about the project: the language, the category ("widget, orm"), and the main thing it replaces.

If your name is a real word, two Reddit and Hacker News options help a lot. Whole Words Only stops widget from matching widgets or widgetry. Case Sensitive makes Widget ignore every lowercase "widget" in normal sentences, which works well when people capitalize your project name.

Last, write excluded keywords for the noise you'll see in the first week. Content is dropped as soon as any one of them appears, so a few words like hiring, job, or the name of an unrelated product with the same name will cut most false matches. All of these filters need the Essential plan or above. Our post on reducing noise in keyword alerts goes deeper on these options.

Where do developers talk about your project?

For most code projects, three places carry the bulk of the public conversation, and they behave differently.

Platform What to watch How fast KWatch checks it
Hacker News Posts and comments 1 second to 1 minute
Reddit Posts and comments, optionally limited to a few subreddits 10 minutes to 1 hour
X Posts and replies 10 minutes to 1 hour

Hacker News is the fast one, and it's also where speed matters most, because a front-page thread moves on in a few hours. Reddit and X can lag by up to an hour, which is fine for a thread that stays active for a day or two.

On Reddit, I'd use Included Subreddits for the name pairs and leave the repo URL alert open to everything. A short list like rust, programming, selfhosted keeps the vague matches out, while the URL alert still catches a link posted in a subreddit you'd never have guessed.

You can also turn on Excluded Users for the team's own accounts. Otherwise every release announcement you post comes back to you as an alert.

Before you rely on this, it's worth knowing what these alerts won't see. They cover public posts on the platforms we monitor, and a few places developers care about aren't on that list. We don't monitor GitHub issues or discussions, Stack Overflow, Discord, or Bluesky. GitHub's own notifications are still the right tool for issues, and if a big part of your community lives on Discord, you'll want a bot inside that server.

Linkedin and Youtube are covered with limits. On Linkedin we watch posts but not comments, and on Youtube we match titles and descriptions, not what's said in the video. For a developer tool, that usually means you'll catch the "we migrated to Widget" post and miss the tutorial that mentions you halfway through.

Send alerts where maintainers already look

Once the keywords are in, the next question is who gets pinged. Email works on every plan, including the free one, and for a solo maintainer it's often enough.

For a team, a shared Slack channel works better. Each alert can post to its own Slack webhook (Business plan and above), so you can split by intent. Repo URL and install-command alerts go to #community, where whoever's on rotation picks them up. Pairs that include a competing library's name can go to whoever writes the comparison docs, since those threads tell you what people are weighing you against.

The AI sentiment tag on each alert helps with triage. A negative Hacker News comment about a bug should jump the queue, and a positive post can wait for a thank you later in the day. Sentiment is measured toward your keyword, and sarcasm still trips it up now and then, so read the post before you reply.

If you want a record over time, add an API webhook on the same alerts and send it to a sheet through Zapier or n8n. Each match arrives as a small JSON payload, like this example:

{
  "platform": "reddit",
  "query": "Keywords: widget, rust",
  "datetime": "09 Nov 26 15:40 UTC",
  "link": "https://www.reddit.com/r/rust/comments/...",
  "author": "some_dev",
  "content": "We swapped our hand-rolled pool for widget last month and the p99 dropped a lot. Docs on config are thin though.",
  "sentiment": "positive"
}

Our Zapier and n8n guide covers the webhook setup step by step.

Turn mentions into project work

A month of logged mentions is more useful than it sounds. It's the one place where you can see what people say about the project when you're not in the room.

Read the negative ones together first. If three people on different platforms say the config docs are thin, that's a docs issue worth opening today. If you add one category alert too (something like orm, rust, recommend), you'll also see threads where someone asked for a tool like yours and nobody named it. Those show you the use cases you haven't written about yet.

The mentions also make a good monthly community update. Linking the best threads in your changelog or newsletter tells contributors their work is being noticed outside GitHub.

Some of the people who keep showing up will matter more than the rest: a framework author, a popular developer on X, a company engineer who migrated to your tool. If you want to follow what those specific people post on Linkedin and X, our sibling product MultiFollow.io does that, which is a different setup from keyword alerts.

Start with your repo URL

The best first step takes two minutes. Create one Hacker News alert and one Reddit alert on your repo path, github.com/yourorg/yourproject, and leave them running for a week. You'll see where your project already gets discussed before you spend time on name pairs and filters.

KWatch's free plan covers 2 Reddit and 2 Hacker News keyword alerts, which is enough for exactly that test. Create your free account and add your repo as your first alert.

Julien, Product Manager at KWatch.io