I got annoyed last month using the public-apis GitHub list. I clicked through ten "free weather APIs" and four were either dead, had silently moved to paid, or required a credit card their docs didn't mention. So I built a thing that watches them.

FreeAPI.watch pings 77 free public APIs every hour, records uptime and response time, and rebuilds a static site daily with the results. The bill is $0/month. Stack is Astro + Cloudflare Workers + D1 + Pages, daily auto-rebuild via GitHub Actions.

This post covers the architecture and the two bugs that ate the most time — including a Cloudflare Workers gotcha I haven't seen documented clearly anywhere.

The architecture

Three components. Each independently deployable, each does one thing.

                ┌────────────────────────────────────┐
                │            Cloudflare              │
                │                                    │
   ┌─────────┐  │  ┌──────────┐  ┌──────────────┐    │
   │ 77 APIs │◀─┼──│  Pinger  │─▶│   D1 (SQL)   │    │
   │ (HTTP)  │  │  │  Worker  │  │              │    │
   └─────────┘  │  │ cron 1h  │  │ apis         │    │
                │  └──────────┘  │ checks       │    │
                │                │ rollups      │    │
                │  ┌──────────┐  │ events       │    │
                │  │ Builder  │◀─┤              │    │
                │  │  Worker  │  └──────┬───────┘    │
                │  │ cron 1d  │         │            │
                │  └──────────┘         │ snapshot   │
                │       │               │ .json      │
                │       │       ┌───────▼─────────┐  │
                │       │       │  Astro static   │  │
                │       └──────▶│  (Pages)        │  │
                │  Pages deploy │  142 HTML pages │  │
                │     hook      └─────────────────┘  │
                │                                    │
                └────────────────────────────────────┘
                              │
                              ▼
                         GitHub Actions
                         daily 02:15 UTC

Pinger is a Cloudflare Worker on an hourly cron. Reads the active API list from D1, sends one HTTP request to each documented health endpoint, records (api_id, ts, status_code, response_ms, alive). On state changes (alive → dead or vice versa), it inserts an event row.

Builder is a second Worker on a daily cron. Rolls up the past 24 hours of checks per API into a rollups table (uptime percentage, average response time), prunes old check rows, and exposes /snapshot.json and /api/v1/* endpoints for the static site to consume.

Astro is a 142-page static site. At build time, it fetches the snapshot from the Builder, generates all pages, and Cloudflare Pages serves them globally. There's no server-side rendering — every page is pure HTML.

The data flow goes one way: pinger writes → D1 → builder rolls up → Astro reads snapshot at build time. The site never queries D1 at request time. This is intentional — static HTML can't fail at runtime, has perfect Core Web Vitals, and Google indexes it cleanly.

The bug that ate an afternoon

When I deployed the first version, the pinger reported every API as offline. Every. Single. One. status_code: 0, response_ms: 0.

My first instinct: network problem. Cloudflare can't reach external HTTPS endpoints. So I wrote a debug endpoint that just did a plain fetch to a known-good URL:

async fetch(req: Request, env: Env): Promise<Response> {
  const r = await fetch("https://api.open-meteo.com/v1/forecast?latitude=52.52&longitude=13.41&current=temperature_2m");
  return Response.json({ status: r.status, ms: 80 });
}

That returned { status: 200, ms: 80 }. Fetch works fine.

Next instinct: my code structure is breaking it. So I tried the actual ping() function with the same URL:

const result = await ping(
  { id: 999, health_url: target, health_method: "GET", expected_status: 200 },
  { fetcher: fetch, now: () => new Date() }
);
return Response.json(result);

Returned status_code: 0, response_ms: 0. The function fails when I pass fetch through dependency injection.

I added error logging to the catch block:

TypeError: Illegal invocation: function called with incorrect `this` reference.
See https://developers.cloudflare.com/workers/observability/errors/#illegal-invocation-errors

In V8 isolates, fetch is implemented with a brand check on this. When you store it as an object property:

const deps = { fetcher: fetch };
await deps.fetcher(url);  // ← `this` is now `deps`, not `globalThis`

The brand check fails synchronously, before any network call is attempted. That's why response_ms was 0 — there was no network roundtrip, just an immediate throw.

The fix is one line:

const deps = { fetcher: fetch.bind(globalThis) };

Or you can call fetch directly without storing it. The whole point of the DI pattern was unit testability — I wanted to inject a mocked fetcher in vitest. Binding to globalThis keeps the same interface and unblocks the tests.

I don't have a great mental model for why this isn't documented more prominently. The Cloudflare error page is good but it's not the first thing you find when you search "cloudflare workers fetch returns 0". I lost an afternoon to it. If you write DI-style Workers, bind your built-ins.

The second bug: the 50-subrequest cliff

Cloudflare Workers on the free tier cap subrequests at 50 per invocation. With 77 APIs to ping, I hit the limit on every cron from day one.

The first thing I tried was filtering to status === "active" (skipping the 6 entries in our "graveyard" of dead/paid APIs). That dropped us to 71. Still over the limit.

The honest disclosure: as of writing this, I'm still over the limit. Each cron run pings the first 50 APIs successfully and silently fails on the remaining 21. The dashboard says the worker "completed" because the loop didn't throw — the fetch() calls just hit the per-invocation cap and resolve as failures.

The fix I haven't shipped yet: split the pinger across two cron schedules. Run one at 0 * * * * covering APIs 1-40, another at 5 * * * * covering APIs 41-77. That stays under the 50 limit per invocation with 10 to spare for D1 writes. It also spreads load across the hour rather than hammering 77 endpoints at the top of the minute.

The other option is paying $5/month for the paid Workers plan, which lifts the limit to 1,000 subrequests. Will probably do that once AdSense approves.

The third bug: Cloudflare Pages deploy hooks don't work for direct upload

I wanted the static site to rebuild daily with fresh data. Cloudflare Pages has deploy hooks which are documented as a way to trigger rebuilds programmatically.

What the docs don't make clear: deploy hooks only work for git-connected Pages projects. My project was deployed via wrangler pages deploy dist/ (direct upload), which means there's no associated git repo, which means no deploy hook URL.

I figured this out after deploying the builder Worker with a triggerPagesDeploy() call that returned 404 every night.

The fix: GitHub Actions. The site repo lives on GitHub. A workflow runs at 15 2 * * * UTC (15 min after the builder rolls up daily data) and does:

- run: pnpm install
- run: pnpm redeploy
  env:
    CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
    CLOUDFLARE_ACCOUNT_ID: 04200558cec0ac55884f5319f5ea0e17

pnpm redeploy runs the Astro build (which fetches snapshot.json from the Builder Worker) then calls wrangler pages deploy. Direct upload, no git connection needed.

The other gotcha here: wrangler tries to enumerate accounts via /memberships if you don't set CLOUDFLARE_ACCOUNT_ID. That requires User:Read scope on the API token, which my deploy token didn't have (and shouldn't, for least-privilege reasons). Setting CLOUDFLARE_ACCOUNT_ID skips the lookup.

The $0 bill, in actual numbers

The only resource I'm anywhere close to capping is the subrequest count per Worker invocation, which is a per-call limit, not a quota. The infrastructure can run at this scale indefinitely without paying anything.

I'd pay $5/month for Workers Paid once the site monetizes via AdSense (pending) or affiliate links (active). Until then, free tier is genuinely enough.

What I'd do differently if starting now

Open-source the repo from day one. I went private during AdSense review (their docs are paranoid about site changes during review). In retrospect this hurts community contribution — devs who'd suggest API additions can't see the seed file. Will flip public after approval.

Connect to GitHub before first deploy. Saves the direct-upload deploy-hook detour. If your Pages project starts git-connected, your daily rebuild can use a simple deploy hook URL instead of a GitHub Actions workflow.

Split the pinger from day one. Don't try to fit 77 subrequests into 50. Two cron triggers offset by 5 minutes is cleaner code and stays within free tier.

Validate response bodies, not just status codes. Right now I check status === 200. But some APIs return 200 with {"error": "key invalid"} in the body — they look alive but they aren't. Adding a JSONPath check per API would catch silent failures.

Where it stands

The site is a week old. Search Console is starting to index. AdSense is in review. The data is real — hourly checks, 30-day rollups, side-by-side comparisons, a graveyard of APIs that have died (Twitter v1.1, Dark Sky, Reddit's free tier, Yahoo Finance, MetaWeather, Weather Underground) with replacement suggestions for each.

If you build on free APIs, take a look: https://freeapi.watch. The data is also exposed as a public JSON API — no auth, CORS open, 5-minute edge cache. Embed status badges in your project READMEs if you want.

What I'd genuinely like feedback on:

1. APIs I'm missing. The seed covers weather, news, finance, geocoding, and crypto. If your category isn't there and there are good free APIs in it, drop a comment with the docs URL.
2. Edge cases in the monitoring. Have you seen APIs that return 200 with errors in the body? That's the silent-failure pattern I want to catch next.
3. The pinger architecture. Splitting across two crons is the obvious next step but if you've solved 50+ subrequests differently I'd love to hear it.

If this was useful, let me know. If you spot something stupid in the architecture, also let me know — I'll fix it.