GitHub Release Monitoring

The scenario

Your team builds on top of a handful of upstream open-source projects - a framework, a database driver, a CLI tool. Each one releases on its own cadence. You need to know when a new stable version ships so you can plan an upgrade, but you don't want to subscribe to every commit, every tag, and every prerelease.

The same pattern fits product teams tracking competitor SDKs, security teams watching dependencies for patched releases, and developer-advocacy teams tracking ecosystem activity.

The problem

GitHub Watch sends way too much noise - every issue, every PR comment, every release candidate. Atom/RSS for releases works but isn't easy to thread into Slack or your own systems. The official GitHub Releases webhook requires admin access to the repo, which you don't have on third-party projects.

How Verid solves it

GitHub's public API exposes https://api.github.com/repos/{owner}/{repo}/releases/latest - unauthenticated, free, and returns clean JSON. Verid polls it on a sensible interval, extracts tag_name, name, and the prerelease flag via JSONPath, and uses a composite predicate to fire only on stable releases.

Build the monitor

Extraction config

{
  "method": "json_path",
  "fields": {
    "tag_name": "$.tag_name",
    "name": "$.name",
    "published_at": "$.published_at",
    "prerelease": "$.prerelease",
    "html_url": "$.html_url"
  }
}

Predicate

Fire when the tag changes AND it's not a prerelease:

{
  "type": "composite",
  "operator": "AND",
  "conditions": [
    { "type": "field_changes", "field": "tag_name" },
    { "type": "field_equals", "field": "prerelease", "value": false }
  ]
}

This is the predicate pattern that makes the difference between "useful" and "noisy" - you'll get exactly one webhook per stable release, with the version number and changelog URL inside.

Create the monitor

Using the template:

curl -X POST https://api.verid.dev/v1/monitors/from-template/github-new-release \
  -H "Authorization: Bearer vrd_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Next.js - stable releases",
    "url": "https://api.github.com/repos/vercel/next.js/releases/latest",
    "deliveries": [
      { "type": "slack", "webhookUrl": "https://hooks.slack.com/services/..." }
    ]
  }'

Or via the SDK with the composite predicate:

import { VeridClient } from '@verid.dev/sdk';

const client = new VeridClient({ apiKey: 'vrd_your_api_key' });

await client.monitors.create({
  name: 'Next.js - stable releases',
  url: 'https://api.github.com/repos/vercel/next.js/releases/latest',
  schedule_interval_seconds: 3600,
  extract_config: {
    method: 'json_path',
    fields: {
      tag_name: '$.tag_name',
      name: '$.name',
      published_at: '$.published_at',
      prerelease: '$.prerelease',
      html_url: '$.html_url',
    },
  },
  diff_predicate: {
    type: 'composite',
    operator: 'AND',
    conditions: [
      { type: 'field_changes', field: 'tag_name' },
      { type: 'field_equals', field: 'prerelease', value: false },
    ],
  },
  deliveries: [
    { type: 'slack', webhookUrl: 'https://hooks.slack.com/services/...' },
  ],
});

What the webhook delivers

{
  "id": "del_01H...",
  "version": "2026-05-01",
  "monitor_id": "9b1c…",
  "fired_at": "2026-05-08T15:30:00Z",
  "diff": {
    "fields_changed": ["tag_name", "name", "published_at", "html_url"],
    "before": {
      "tag_name": "v16.1.4",
      "name": "v16.1.4",
      "published_at": "2026-04-22T18:11:00Z",
      "prerelease": false,
      "html_url": "https://github.com/vercel/next.js/releases/tag/v16.1.4"
    },
    "after": {
      "tag_name": "v16.2.0",
      "name": "v16.2.0",
      "published_at": "2026-05-08T15:25:00Z",
      "prerelease": false,
      "html_url": "https://github.com/vercel/next.js/releases/tag/v16.2.0"
    }
  }
}

Your Slack alert can format this into a one-line "Next.js v16.2.0 just shipped" with a link to the changelog.

Caveats & tips

• The /releases/latest endpoint skips prereleases by construction. If you want to monitor prereleases (RCs, betas), point at /repos/{owner}/{repo}/releases and watch the first array element. The composite predicate then becomes more important.
• GitHub rate limits unauthenticated calls. 60 requests per hour per IP. One monitor per repo running hourly is well within budget; fifty monitors hourly is not. For high-volume tracking, attach an authenticated token via custom headers on the monitor.
• Tag schemes vary. v1.2.3, 1.2.3, and release-1.2.3 are all common - your downstream consumer should treat tag_name as an opaque string, not parse it.

Related use cases

For npm-specific tracking, see NPM package version tracking. For PyPI, see PyPI package updates. For any other JSON API field, see JSON API field monitoring.