Understanding lastUpdatedAt

One of the most important distinctions in Watch Changelog is lastUpdatedAt vs. lastFetchedAt.

The Difference

• lastUpdatedAt: The vendor's own published timestamp. When they say the update was published.
• lastFetchedAt: When we fetched the changelog from their site.

Why This Matters for GTM

Imagine you're tracking cloud provider updates for competitive intelligence:

• Vercel publishes a new edge middleware feature at 9:00 AM PST
• We fetch their changelog at 9:30 AM PST
• You query Watch Changelog at 10:00 AM PST

Without the distinction, you'd see "updated 30 minutes ago" (our fetch time) instead of "updated 1 hour ago" (their publish time). That 30-minute gap makes it look like the vendor just shipped—when really they shipped an hour ago and you're catching up.

For sales enablement, that hour matters. Your competitor might already be pitching it.

How We Track It

1. RSS/Atom feeds: We parse <pubDate> or <updated> from the feed
2. GitHub releases: We use published_at from the GitHub API
3. HTML changelogs: Best-effort extraction of dates from the page

If a vendor doesn't publish dates, lastUpdatedAt is null. We never fake it with fetch time.

Sort by Company Time

On the homepage and catalog, "Recently Updated" sorts by lastUpdatedAt, not lastFetchedAt. This means you see vendors who actually shipped something recently, not vendors we happened to fetch recently.

Degraded sources (failing to fetch) are marked "Being investigated by the team" and deprioritized in the sort.

API Example

{
  "slug": "vercel.changelog",
  "vendor": "Vercel",
  "name": "Vercel Changelog",
  "lastUpdatedAt": "2026-08-20T09:00:00Z",  // Vendor time
  "lastFetchedAt": "2026-08-20T09:30:00Z",  // Our fetch time
  "health": "ok"
}

This field is exposed in:

• GET /api/v1/sources
• Source detail pages
• MCP list_sources tool

Next Steps

Browse sources by recently updated or request a new source.