GitHub Release & Changelog Monitor API

Source-led, self-serve monitoring for GitHub releases, release notes, tags, and changelog drift.

This actor is optimized for low-maintenance, summary-first watchlists:

• start with a list of repositories
• let the actor use GitHub releases.atom and tags.atom by default
• optionally add a changelog URL when you want extra detail
• get back one repository summary row per repo, not a flood of raw page diffs

Store quickstart

• Start with store-input.example.json for a reliable first run across two public repositories.
• If the output fits your workflow, switch to store-input.templates.json and choose one of:
  • Quickstart (2 repos, dataset) for first success
  • Recurring Team Watchlist for a recurring internal release watch lane
  • Webhook Release Digest when Slack, ticketing, or internal automation should receive only routed release summaries

Billing / value unit: one repository summary per repo on each run. You can watch multiple GitHub surfaces for the same repo, but they still roll up into that single summary row.

Default source model

For each repository, the actor can watch:

• Releases → https://github.com/<owner>/<repo>/releases.atom
• Release notes → same feed, treated as a separate summary surface when you want a dedicated release-note lane
• Tags → https://github.com/<owner>/<repo>/tags.atom
• Changelog → optional changelogUrl you provide (raw markdown URLs are recommended)

That keeps the product source-led and low-maintenance: public GitHub feeds plus an optional changelog source when a team wants a richer watchlist.

What the actor gives back

Each repository result includes:

• status and severity
• reason and executiveSummary
• recommendedActions
• repositorySummary.changedSurfaces
• signals such as breaking, action_required, deprecation, security, and incident
• changes[] with structured source-level evidence
• recurringDigest for scheduled watchlists and webhook delivery
• actionNeeded[] rows for downstream routing

Why this is stronger than a generic diff actor

Generic diff tools stop at “something changed.” github-release-monitor adds a summary-first decision layer around GitHub release activity:

• one repository row instead of many unrelated source rows
• one severity for prioritization
• one short reason for human review
• one recommended action set for engineering / platform owners
• one recurring digest for webhook or scheduled review

That makes it a better greenfield lane for recurring release watchlists, dependency monitoring, platform watch, and webhook digests.

Input example

{
  "repositories": [
    {
      "id": "axios",
      "name": "Axios",
      "repo": "axios/axios",
      "criticality": "high",
      "owner": "Platform",
      "tags": ["sdk", "http-client"],
      "modes": ["releases", "tags", "changelog"],
      "changelogUrl": "https://raw.githubusercontent.com/axios/axios/v1.x/CHANGELOG.md"
    },
    {
      "id": "apify-crawlee",
      "name": "Apify Crawlee",
      "repo": "apify/crawlee",
      "criticality": "standard",
      "owner": "Automation",
      "modes": ["releases", "tags"]
    }
  ],
  "delivery": "dataset",
  "datasetMode": "changes_only",
  "snapshotKey": "github-release-monitor-team-watchlist",
  "diffMode": "line_summary",
  "summaryMaxLines": 12,
  "concurrency": 2
}

Advanced users can override defaults with per-surface configs under surfaces, including custom URLs, include/exclude patterns, or fixture HTML for local testing.

Output example

{
  "repositoryId": "axios",
  "repositoryName": "Axios",
  "repo": "axios/axios",
  "status": "changed",
  "severity": "high",
  "signals": ["action_required", "deprecation"],
  "recommendedActions": [
    "Review the latest GitHub release notes with Platform and decide whether upgrade, regression-test, or compatibility work is needed.",
    "Read the changelog diff and extract migration, configuration, or rollout work for Platform."
  ],
  "repositorySummary": {
    "changedSurfaces": ["releases", "changelog"],
    "actionNeeded": true
  }
}

A fuller payload is available in sample-output.example.json.

Delivery modes

• dataset: saves summary-first repository rows to the dataset (or local output when Apify dataset env vars are unavailable)
• webhook: sends meta, recurringDigest, actionNeeded, and selected repository rows
• email: placeholder for MVP parity with existing repo patterns

datasetMode controls which repository summaries are delivered:

• action_needed: only follow-up rows
• changes_only: rows with changed, initial, partial, or error status
• all: every monitored repository row

Template catalog

Template	Best for
Quickstart (2 repos, dataset)	first success with two public repositories
Recurring Team Watchlist	internal recurring release watchlists across multiple dependencies or platforms
Webhook Release Digest	Slack / ITSM / internal automation routing for action-needed release summaries

Recommended first recurring run:

• 2-5 repositories
• datasetMode=changes_only
• diffMode=line_summary
• stable snapshotKey
• concurrency=2

Local run

cd /volume1/docker/Apify/github-release-monitor
cp -n .env.example .env
cp -n input.example.json input.json
./scripts/run-with-env.sh
cat output/results.json

The bundled input.example.json is fixture-based and safe for offline local verification. For Store-oriented live examples, use store-input.example.json or the recurring templates.

Tests

cd /volume1/docker/Apify/github-release-monitor
npm test

Notes

• First run is expected to return repository rows with status=initial.
• Stable snapshotKey values matter: recurring value comes from comparing the same repository watchlist over time.
• Raw changelog URLs are preferred over rendered HTML pages when available.
• actionNeeded and recurringDigest are the intended webhook-first surfaces.
• The actor stays summary-first by rolling multiple monitored sources into one repository row.

Related actors

• site-governance-monitor — pair release monitoring with docs, pricing, sitemap, schema, and release-QA drift checks after a product or docs deploy.
• vendor-change-monitor — pair release watchlists with pricing-page, terms-of-service, renewal, or policy monitoring for SaaS vendors.

Portfolio workflow:

• catch the release in github-release-monitor
• validate public-site rollout in site-governance-monitor
• monitor commercial or policy drift in vendor-change-monitor

Reuse lineage

This actor reuses and adapts patterns from:

• vendor-change-monitor — summary assembly, recurring digest, dataset/webhook delivery
• saas-change-monitor-actor — fetch, extract, diff, and snapshot persistence foundation