Meerkat

Meerkat is my repo and CI status dashboard — a service that knows about every repo I maintain and can tell me at a glance which are green, which are red, and which have pull requests waiting on me.

It watches a configured list of repos, polls GitHub for their CI status and open PRs on a short interval, and serves results from an in-memory cache so reads never block. Alongside the live view it keeps a durable PostgreSQL registry of each project’s metadata — description, URL, local path, prefix — with a deterministic UUID derived from the owner/repo slug, so other tools on my platform can look a project up without hardcoding it.

Meerkat is my personal repo and CI status tracking dashboard service — a service that knows about every repo I maintain and can tell me, at a glance, whether it’s green, red, or has PRs waiting on me.

Why I Built It

I have dozens of repos scattered across GitHub — services, sites, CLIs, experiments — and no single place to see which ones are broken, which have open pull requests, or even just what they’re called and what they’re for. Checking each one individually doesn’t scale. I wanted a lightweight service that watches a configured list of repos, polls GitHub for their live CI status and open PRs on a short interval, and also keeps a durable, editable record of each project’s metadata (description, URL, local path, prefix) so other tools in my platform — like the jh CLI — can look projects up by slug or UUID instead of hardcoding them.

Meerkats stand sentinel and watch for danger — a fitting namesake for a service whose whole job is watching a burrow of repos and flagging trouble before it spreads.

What It Does

• Tracks a fixed set of GitHub repos (WATCHED_REPOS) and refreshes their CI status and open PRs on a timer, serving results from an in-memory cache so reads never block on GitHub.
• Derives a simple passing / failing / pending / unknown CI status per repo from its most recent workflow runs.
• Maintains a durable projects table in PostgreSQL — one row per repo, holding name, description, URL, local path, prefix, and active/archived status — separate from and longer-lived than the live GitHub cache.
• Seeds a project row for every watched repo on startup, without ever overwriting fields I’ve already edited through the API.
• Exposes it all over two ConnectRPC services: StatusService for live CI/PR data, ProjectService for CRUD on project metadata.
• Assigns every project a deterministic UUID v5, derived from its owner/repo slug, so any service can compute the same ID independently without a lookup.