How to Monitor GitHub for Brand and Keyword Mentions (2026)

GitHub is one of the richest sources of unfiltered developer intent available publicly. When a developer opens an issue saying "looking for an alternative to X," comments on a PR asking "does anyone have experience with Y," or writes a commit message mentioning a specific technology stack — those are buying signals. Monitoring GitHub for brand and keyword mentions gives you a real-time window into what developers are actively thinking about, evaluating, and deciding to buy.

What to Monitor on GitHub

• Issues: Developers describe problems, ask for tool recommendations, compare solutions
• Pull Requests: Code comments often mention specific tools being adopted or replaced
• Discussions: GitHub Discussions are used for community Q&A and architectural decisions
• Commit messages: Indicate tools being adopted (e.g., "migrate from X to Y")
• README files: Track when projects add or remove your tool from their stack lists
• Code: Direct imports, package.json entries, requirements.txt — real adoption signals

Method 1: GitHub Search API for Keyword Monitoring

The GitHub Search API supports searching across Issues, PRs, discussions, and code. The key endpoint for monitoring is /search/issues, which covers both Issues and Pull Requests:

# Search Issues and PRs for brand mention in the last 24 hours
curl -H "Authorization: Bearer YOUR_TOKEN" \
  "https://api.github.com/search/issues?q=YOUR_BRAND+created:>2026-04-23&sort=created&order=desc"

# Search for competitor comparison mentions
curl -H "Authorization: Bearer YOUR_TOKEN" \
  "https://api.github.com/search/issues?q=%22alternative+to+YOUR_COMPETITOR%22+is:open"

# Search code for direct import/usage
curl -H "Authorization: Bearer YOUR_TOKEN" \
  "https://api.github.com/search/code?q=YOUR_PACKAGE+in:file+language:javascript"

Rate Limits and Pagination

The Search API allows 30 requests per minute for authenticated requests. Results are capped at 1,000 per query. For ongoing monitoring, page through results using the Link header and track the highest created_at timestamp from your last poll to avoid re-processing results. Store the cursor server-side.

import requests
import time

def poll_github_mentions(keyword: str, token: str, since: str) -> list:
    """Poll GitHub Issues/PRs for keyword mentions since a given timestamp."""
    headers = {"Authorization": f"Bearer {token}"}
    results = []
    page = 1

    while True:
        resp = requests.get(
            "https://api.github.com/search/issues",
            params={
                "q": f"{keyword} created:>{since}",
                "sort": "created",
                "order": "asc",
                "per_page": 100,
                "page": page,
            },
            headers=headers,
        )

        # Respect rate limits
        if resp.status_code == 403:
            reset_time = int(resp.headers.get("X-RateLimit-Reset", time.time() + 60))
            time.sleep(reset_time - time.time() + 1)
            continue

        data = resp.json()
        results.extend(data["items"])

        if "next" not in resp.links:
            break
        page += 1

    return results

Method 2: GitHub Webhook Events

For repos you own or administer, GitHub Webhooks deliver real-time events for issues, pull_request, discussion, and create events. This is faster and cheaper than polling the Search API, but limited to repos where you have admin access.

// Express webhook handler for GitHub issue events
import crypto from 'crypto';

function verifySignature(payload: string, signature: string, secret: string): boolean {
  const expected = 'sha256=' + crypto
    .createHmac('sha256', secret)
    .update(payload)
    .digest('hex');
  return crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected));
}

app.post('/webhook/github', (req, res) => {
  const sig = req.headers['x-hub-signature-256'] as string;
  if (!verifySignature(JSON.stringify(req.body), sig, process.env.WEBHOOK_SECRET!)) {
    return res.status(401).send('Invalid signature');
  }

  const event = req.headers['x-github-event'];
  const payload = req.body;

  if (event === 'issues' && ['opened', 'edited'].includes(payload.action)) {
    const body = payload.issue.body || '';
    const KEYWORDS = ['your-brand', 'competitor-name', 'problem-keyword'];
    const matched = KEYWORDS.filter(k => body.toLowerCase().includes(k));

    if (matched.length > 0) {
      // Push to your CRM or Slack
      notifyTeam(payload.issue, matched);
    }
  }

  res.status(200).send('OK');
});

Method 3: GraphQL API for Discussion Monitoring

GitHub Discussions are not covered by the REST Search API. To monitor discussions, use the GraphQL API with a search query:

query MonitorDiscussions($keyword: String!) {
  search(query: $keyword, type: DISCUSSION, first: 20) {
    nodes {
      ... on Discussion {
        id
        title
        body
        url
        createdAt
        author {
          login
        }
        repository {
          nameWithOwner
        }
      }
    }
  }
}

Building an Automated Monitoring Pipeline

A production-grade GitHub monitoring pipeline needs: (1) a polling scheduler that runs every 5–15 minutes, (2) deduplication to avoid re-processing seen items, (3) keyword matching with context extraction, (4) lead enrichment from the GitHub user profile, and (5) delivery to your CRM or Slack. This is a non-trivial engineering project — expect 2–4 weeks to build reliably, or use GitLeads to skip the build entirely.

GitLeads provides this pipeline out of the box: configure your brand keywords and competitor names, connect your CRM or Slack destination, and receive enriched lead profiles whenever a relevant mention fires on GitHub. The free tier covers 50 leads/month — more than enough to validate the signal before scaling. See also: how to find leads on GitHub, GitHub intent data for B2B sales.