Skip to content
RaidKit
Sign up
All packs

Capability pack

Operations

Not a feature anyone asks for, and the first thing missed. Errors captured to a table you can read without a vendor, structured logs, a background queue that retries with backoff instead of losing the email, feature flags to turn something off without a deploy, and a public API with keys that can be revoked.

Capabilities

8

All of them are built.

Watched in production

0

8 have never been watched against a real provider.

Provider variables for a fresh project

3

Including the packs it sits on. 2 unset here, each running its documented fallback.

Needed regardless of providers

  • A scheduler that calls the cron routes with CRON_SECRET (Vercel cron, or anything that can send a header on a timer).

What is in it

Each row links to where it lives, and carries the state it has in THIS deployment.

  • Error monitoring

    Fallback

    Every uncaught server error — render, route, action, middleware — and a visitor's blank page are captured, grouped by fingerprint on /admin/errors, and kept 30 days. The same event goes to Sentry over plain HTTP when a DSN exists; no SDK.

    Needs SENTRY_DSN. Without it: Errors are grouped in the first-party table at /admin/errors and kept 30 days.

    instrumentation.ts + ErrorEvent table; Sentry forward when SENTRY_DSN is set

  • Feature flags

    Ready

    A switch the code consults, decided per person: code default, then an admin's override with a percentage, an audience, and a text payload, then an environment pin that wins over both. Rollouts are stable per subject. The announcement banner and the quote form consult theirs; /api/flags serves client code. Every flip is audited.

    Definitions in code, FeatureFlag overrides, FLAG_OVERRIDES env pins, FNV-1a buckets

  • Scheduled jobs

    Ready

    A nightly sweep of expired tokens, abandoned uploads, stale guest carts, and unpaid orders that never reached a payment provider — an order holding a Stripe session is cancelled only by Stripe's answer, never by the clock, and the ones still waiting are counted into the audit row. Idempotent, bearer-guarded, audited.

    Vercel Cron + a guarded route handler

  • Rate limiting

    Ready

    Keyed per caller, so an abuser is throttled and not the site. Durable by default: one atomic upsert per hit holds the limit across serverless instances; RATE_LIMIT_STORE=memory keeps the per-process limiter, which is also the fallback if the database call fails.

    Postgres fixed windows (atomic upsert), or in-memory

  • Public API keys

    Ready

    A member mints a key in Settings, sees it once, and a program sends it as a bearer token. Every endpoint names the scope it needs; wrong scope is 403, anything dead is 401, and each key has its own rate bucket. The game is fully playable by API through the same service the console uses, version lock included.

    ApiKey rows (hash + display prefix), scopes in code, per-key rate limit, /api/v1

  • Analytics

    Fallback

    One beacon per navigation counts a view per (day, path) and a distinct visitor per day from a salted hash that cannot be linked across days. No cookie, no ip stored, crawlers and private pages excluded, Global Privacy Control honored. /admin/analytics charts real rows.

    Needs NEXT_PUBLIC_VERCEL_ANALYTICS. Without it: First-party cookieless page views are recorded and charted at /admin/analytics.

    First-party page views (cookieless); Vercel Web Analytics beside it when enabled

  • Security headers

    Ready

    Clickjacking, MIME-sniffing, and referrer-leak mitigations.

    Next.js middleware

  • Continuous integration

    Ready

    Both suites on every push — and its first two runs each found a real bug.

    GitHub Actions

First steps in a fork

  1. 1Set CRON_SECRET so the scheduled routes will run, and check that Vercel is calling them.
  2. 2Point SENTRY_DSN somewhere if you want alerts; the errors table works either way.
  3. 3Read /admin/errors after the first deploy, not after the first complaint.

What to delete

  • Nothing. Every fork wants this one, and every fork leaves it out.

Provider variables a fresh project would set

  • CRON_SECRET
  • NEXT_PUBLIC_VERCEL_ANALYTICS
  • SENTRY_DSN

Shaded green: set on this deployment.

The full inventory, with the tests that cover each capability and what has actually been watched working.

Capability inventory