Error log

Audience

This article is for GCM platform operators. Church admins should see the Audit log article in Users & Roles for changes they can investigate themselves — the Error log is platform-wide and includes stack traces and request bodies, which are GCM staff-only by design.

The Error log tab (/platform/error-log) is the central triage queue for everything that explodes anywhere in the system. Frontend exceptions caught by the Sentry boundary, edge functions that throw, Vercel API routes that 500, and database triggers that raise — they all converge into platform_error_log and surface here, filterable by source, severity, org, and resolved state, auto-refreshing every 30 seconds.

The five sources

Every row carries a source enum. The filter dropdown lets you narrow to one at a time:

• Frontend — uncaught React exceptions. Captured by the global error boundary and posted via /api/log-error. The url and user_agent fields are filled in.
• Edge function — Deno edge functions that threw or called log() with severity error. The function_name column is set.
• Vercel API — Node serverless functions (the /api/* routes). Like edge functions but with the Vercel runtime context.
• DB trigger — raised from inside Postgres, usually by a RAISE EXCEPTION in a trigger. Stack trace is the Postgres error context.
• Manual — anything log_error was called for explicitly. Used for non-fatal warnings worth surfacing.

Severity

Three levels, all colour-coded:

• warning — amber. Not failing requests, but loud enough to investigate. RLS denials, slow queries, retried gateway calls.
• error — rose. A request failed. The user saw something broken.
• fatal — deep red. A request failed in a way that left state inconsistent. Treat as page-one.

The default filter is "unresolved"

The page loads with resolved = false so the queue is what is open. Toggle to Resolved to view triaged history, or All for a full view. The Org filter has a special Unattributed (no org) option for rows that fired before a tenant context was established (the most common case for frontend boot-up errors).

The text search hits four columns at once: message, function_name, url, error_code. Use it the way you would use Sentry's search — partial match, case-insensitive.

What a row looks like

Each row in the table shows:

• When — relative ("3m ago"). Hover for the full timestamp.
• Source — coloured icon + label.
• Severity — pill.
• Org — derived from context.org_name when present, else the first 8 chars of organization_id, else a dash.
• Message — the error message, truncated.
• Where — function_name if available, otherwise url.
• Status — Open or Resolved.

Click any row to open the detail dialog.

The detail dialog

The detail dialog is the triage workspace. Top half is a key/value grid: function / URL, error code, user (name + email), org + plan, the roles they had, whether they were a platform admin at the time, route, action context, correlation id, user agent.

Two collapsible sections follow:

• Stack trace — the raw stack from the runtime. For DB triggers this is the Postgres error context. For frontend errors it is the JS stack, source-mapped when possible.
• Context (full) — the entire context JSONB column pretty-printed. This is where edge functions stash request bodies, query params, and intermediate values. Treat it as sensitive — it can include emails and IDs.

PII in context

The context column is not redacted. It is a raw dump of whatever the failing code captured. Do not paste it into Slack, into a public ticket, or into a Sentry issue. The Error log lives behind platform admin gate precisely so this is safe.

Resolving a row

The bottom of the dialog has the resolution controls:

• Mark resolved — captures an optional note ("fixed in #123" or "transient, ignoring") and stamps resolved, resolved_at, resolved_by, resolved_note. The row drops out of the default unresolved view.
• Reopen — only visible on already-resolved rows. Clears the resolution columns.
• Delete — destructive. Drops the single row entirely. Useful for personal-data exposures that should not stay in the database.

Resolution is a workflow signal, not a fix. Marking a row resolved does not stop the underlying bug — it just tells your future self the error has been triaged.

Bulk actions

Two bulk operations live in the table header:

Purge resolved > 30d

Permanently deletes resolved rows older than 30 days. This is the retention sweep — a triaged row earns no rent past a month. Cheap to run, safe to run regularly. The button reports the count it removed.

Clear filtered

Deletes every row matching the current filter set. This is dangerous and the UI knows it:

• The button is disabled unless at least one filter narrows the set. Without a filter, the dialog's "matching the current filters" copy would be a lie.
• The confirmation dialog shows the exact count it will delete.

Use this to wipe a noisy class of warnings after you have shipped the fix: filter to source = frontend, message = ChunkLoadError, resolved = unresolved, hit Clear, watch the count zero out.

What the auto-refresh means

The query refetches every 30 seconds via React Query's refetchInterval. The loading spinner appears inline next to the row count on each refetch — if it is spinning forever, the network is wedged and the existing rows are stale. The Refresh button forces an immediate invalidation.

Common patterns

A spike of EDGE_FUNCTION warnings from one org — usually a misconfigured webhook hammering an endpoint that returns 429. Open the org and check their channels rows.

Fatal errors with no org — the failure happened before the tenant context resolved. Frontend boot crashes, auth-hook misfires, and edge-fn cold-start failures cluster here. Group by message and the cause is usually a missing env var.

RLS-denial errors from db_trigger — somebody is calling a query without the right role. Cross-reference the user id in context with the audit log to see what they were trying to do.

If a single row needs investigation by an engineer who is not a platform admin, copy the correlation_id and share that — they can grep the edge-function logs in Supabase for the same id without you having to forward the row.