{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "statusbeam-worker",
  "main": "src/index.ts",
  "compatibility_date": "2026-07-01",
  "compatibility_flags": ["nodejs_compat"],

  // Run the check loop on a schedule. GitHub Actions cron is best-effort;
  // Cloudflare Cron Triggers fire on time. Default: every 5 minutes.
  "triggers": {
    "crons": ["*/5 * * * *"]
  },

  // The Worker also serves a `fetch` handler for inbound provider webhooks at
  // `POST /webhooks/:provider/:slug` (src/webhook.ts) — real-time status updates
  // alongside the cron backstop. Supported providers: `statuspage` and `sentry`.
  // It's reachable at the *.workers.dev URL by default; authenticate it with a
  // shared secret:
  //   wrangler secret put WEBHOOK_SECRET
  // then register the URL on the provider as
  //   https://<worker>.workers.dev/webhooks/statuspage/<slug>?token=<secret>
  //   https://<worker>.workers.dev/webhooks/sentry/<slug>?token=<secret>
  // See docs/adapters/{statuspage,sentry}.md for setup. When WEBHOOK_SECRET is
  // unset the endpoint fails closed (every request → 401).
  //
  // Sentry poll backstop (optional): a `check: sentry` site with a `sentry:`
  // block is also polled against Sentry's Issues API each cron tick when a token
  // is set. Provide it as a secret; without it, `check: sentry` sites are
  // webhook-only (cron skips them):
  //   wrangler secret put SENTRY_AUTH_TOKEN   # read access to issues

  // Time-series checks + incident history.
  "d1_databases": [
    {
      "binding": "DB",
      "database_name": "statusbeam",
      "database_id": "REPLACE_WITH_D1_DATABASE_ID"
    }
  ],

  // Current snapshot (the summary the status page reads at the edge) + config.
  "kv_namespaces": [
    {
      "binding": "STATUS_KV",
      "id": "REPLACE_WITH_KV_NAMESPACE_ID"
    }
  ]

  // Notifications (src/notify.ts): dispatched inline via `ctx.waitUntil(fetch)`
  // on a status change — Slack + generic webhook targets come from the
  // `notifications` block in status.config.yml, so no binding is required for
  // the default (free-plan) inline path.
  //
  // Reliable delivery (opt-in): set `notifications.delivery: queue` in
  // status.config.yml and uncomment the block below. Cloudflare Queues is on the
  // Workers Free plan (10k ops/day, 24h dead-letter retention); the Paid plan
  // raises those limits and extends retention to 14 days. On a status
  // change (from either the `scheduled` cron or an inbound Statuspage webhook),
  // the producer enqueues one message per target onto NOTIFY_QUEUE and the
  // `queue` consumer (src/index.ts) does the HTTP dispatch — gaining automatic
  // retries + backoff and dead-lettering. Create the queues first:
  //   wrangler queues create statusbeam-notifications
  //   wrangler queues create statusbeam-notifications-dlq
  // then add a comma after the `kv_namespaces` `]` above and uncomment:
  //
  // "queues": {
  //   "producers": [
  //     { "queue": "statusbeam-notifications", "binding": "NOTIFY_QUEUE" }
  //   ],
  //   "consumers": [
  //     {
  //       "queue": "statusbeam-notifications",
  //       "max_retries": 5,
  //       "dead_letter_queue": "statusbeam-notifications-dlq"
  //     }
  //   ]
  // }
  //
  // Cache purge (src/cache.ts): purge-by-Cache-Tag is a REST API feature (on all
  // Cloudflare plans since Apr 2025), not a Worker binding. Provide these as
  // secrets and the web app
  // must emit a matching `Cache-Tag` response header:
  //   wrangler secret put CF_API_TOKEN   # token with "Cache Purge" permission
  //   wrangler secret put CF_ZONE_ID     # zone serving the status page
  // When unset, cache purge is skipped (logged, not fatal).
}