Production Field Note / 01Updated 14 July 2026 · Next.js · Supabase · Vercel
A practical production-readiness guide

Your dashboard is green. Your SaaS workflow is dead.

Uptime and exception monitoring cannot prove that a business workflow is still moving. Separate three signals, verify the data boundary, and make canary success measurable.

Illustrative incident · 14:07
HTTP 200. No new exceptions. Every active driver's GPS update is 26 minutes old.

Three signals, three questions

Teams often monitor whether the application responds and whether code throws, but not whether the work users depend on is progressing. Treat these as separate claims:

SIGNAL A

Availability

Can users reach the application and its critical endpoints?

SIGNAL B

Exceptions

Did code fail while handling a request or background operation?

SIGNAL C

Freshness

Is the business process moving inside its declared time boundary?

Vercel Observability exposes request, function, external API and routing events. Vercel Alerts can notify on error-rate and usage anomalies. Those signals are useful, but a workflow may still stall without a 5xx response or uncaught exception.

Write the third signal in the language of the operation: every paid invoice creates an entitlement within 60 seconds; every queued generation reaches a visible terminal state; every active driver's latest accepted update is younger than the agreed threshold.

select driver_id, max(recorded_at) as latest_update
from driver_locations
where shift_status = 'active'
group by driver_id
having max(recorded_at) < now() - interval '10 minutes';

This query is illustrative. Real thresholds must reflect declared shift windows, expected update intervals, offline behavior and known coverage gaps. The invariant is the important part: an active workflow cannot silently age past its agreed boundary.

Authorization before observability polish

For a Supabase application, the first production gate is usually the data boundary. Supabase states that Row Level Security should always be enabled for tables in exposed schemas such as public. Policies then define which rows each role may read or modify.

  1. Is RLS enabled on every exposed tenant, user, job, location and billing table?
  2. Which roles have object privileges?
  3. Which policy protects each operation?
  4. Can a test user access another user's row?
  5. Does the API route check ownership as well as authentication?
  6. Can a service-role key reach any client-side path?

“The user must be logged in” is not an ownership rule.

A success log does not prove retention

If the system promises to remove records after 90 days, the job must record what it selected, changed, skipped and rejected. Then a separate query must prove that no eligible rows remain outside the boundary.

selected=1842 deleted=1839 rejected=3
verification_remaining=0

“The function returned 200” and “the intended state now exists” are different claims.

Backups are a feature. Recovery is a procedure.

Supabase documents daily backups for Pro, Team and Enterprise projects and Point-in-Time Recovery for finer recovery windows. It also notes that database backups do not restore deleted Storage API objects.

  • What is actually backed up?
  • What is the available recovery window?
  • Which data is outside that backup?
  • Who can initiate a restore?
  • What downtime and post-restore work should the team expect?
  • Has the procedure been rehearsed with non-production data?

Give the canary business criteria

Start with two or three consenting users, drivers or internal operators. Before the canary, resolve P0 findings, identify the last known-good deployment, define the rollback trigger and verify that alerts reach a person outside the failing system.

Vercel Instant Rollback can restore an earlier production deployment. Its documentation notes that a rolled-back build's configuration may be stale, environment-variable changes are not applied to that older build, and cron jobs return to the rolled-back deployment's state. Recovery planning therefore includes external systems and data compatibility—not only routing.

A canary succeeds only when the business invariant holds, not merely when the page loads.

A bounded 48-hour production gate

P0Blocks a safe canary.
P1Fix before broad production trust.
P2Lower-urgency hardening.

Every finding should cite a file and line, redacted screenshot, redacted log excerpt, client-run staging query, or explicit negative evidence that a control is absent. The output is a prioritized backlog, canary plan, rollback triggers and incident runbook—not a promise of perfect security, legal compliance or zero incidents.

See the exact courier TMS scope.

The fixed £200 audit states the access boundary and 48-hour deliverables before any work begins.

Review the production-readiness offer

Primary sources