Dashboards & Analytics · Automation Health

Automation Failure Monitor Dashboard

A monitor that surfaces automation and webhook failures from the monitoring event log so silent breakages get seen the same day instead of weeks later.

Start a ProjectAll Case Studies
4 to 7 days
build time
4
outcomes
5
stack tools
6
build steps

Built with real HMX dashboard tool paths

Supabase Postgresmonitoring_events table (existing)SQL viewNext.js 16 server componentsVercel hostingSupabase Postgresmonitoring_events table (existing)SQL viewNext.js 16 server componentsVercel hosting

01 // Outcomes

Outcome signals

Failures
from the event log surfaced same-day
Per-type
counts for webhook, send, and rate-limit events
Recent
failure feed for fast triage
Healthy
empty state reads clearly as all-clear

Case architecture

Automation Failure Monitor Dashboard Architecture

6 nodes
Inventory the event types
Agree the rolling window and
Supabase Postgres
monitoring_events table
Review Queue
Dashboard Action
  1. 01Inventory the event types

    A monitor that surfaces automation and webhook failures from the monitoring event log so silent breakages get seen the same day instead of weeks la...

  2. 02Agree the rolling window and

    Agree the rolling window and which event types are urgent vs informational.

  3. 03Supabase Postgres

    Supabase Postgres contributes the trusted model for Automation Failure Monitor Dashboard so metrics are defined before they are visualized.

  4. 04monitoring_events table

    Build a view counting failures per type over the window plus a recent-failures detail feed.

  5. 05Review Queue

    When automation confidence is low, route the record to a manual owner with the source, stage, and last action attached.

  6. 06Dashboard Action

    Failures from the event log surfaced same-day; Per-type counts for webhook, send, and rate-limit events; Recent failure feed for fast triage; Healt...

Problem

The operating gap

When an automation or webhook quietly fails, leads stop syncing or emails stop sending and nobody notices until a client asks why they never heard back — the failures are logged somewhere but never looked at.

Build

What gets built

A read-only dashboard over the monitoring_events table that counts and lists failure-type events (webhook errors, Turnstile failures, send failures, rate-limit hits) over a rolling window, grouped by event type with a recent-failures feed. It reads the existing monitoring log and makes the failures impossible to miss.

Build steps

How it ships

Automation Failure Monitor Dashboard uses a reporting model and review layer for Dashboards. A monitor that surfaces automation and webhook failures from the monitoring event log so silent breakages get seen the same day instead of weeks la... The architecture connects inventory the event types, supabase postgres, monitoring_events table, and dashboard action with an explicit control path.

  1. 01Inventory the event types already written to monitoring_events and classify which ones represent failures.
  2. 02Agree the rolling window and which event types are urgent vs informational.
  3. 03Build a view counting failures per type over the window plus a recent-failures detail feed.
  4. 04Render the dashboard with per-type failure counts, a trend line, and the latest failure events.
  5. 05Add a 'no failures recorded' state so an empty board reads as healthy, not broken.
  6. 06Document each event type so an operator knows what each failure category means.

Stack

Tools and layers

  • Supabase Postgres
  • monitoring_events table (existing)
  • SQL view
  • Next.js 16 server components
  • Vercel hosting
  • Inputs layer: Inventory the event types already written to monitoring_events and classify which ones represent failures.
  • Transform layer: Agree the rolling window and which event types are urgent vs informational.
  • Metrics layer: Supabase Postgres contributes the trusted model for Automation Failure Monitor Dashboard so metrics are defined before they are visualized.
  • Visualization layer: monitoring_events table (existing) handles refresh, review, or reporting delivery while a read-only dashboard over the monitoring_events table that counts and lists failure-type events (webhook errors, Turnstile failures, send failures...
  • Action layer: Failures from the event log surfaced same-day; Per-type counts for webhook, send, and rate-limit events; Recent failure feed for fast triage; Healt...

Data flow

  1. 01Inventory the event types already written to monitoring_events and classify which ones represent failures.
  2. 02Agree the rolling window and which event types are urgent vs informational.
  3. 03Build a view counting failures per type over the window plus a recent-failures detail feed.
  4. 04Render the dashboard with per-type failure counts, a trend line, and the latest failure events.
  5. 05Add a 'no failures recorded' state so an empty board reads as healthy, not broken.
  6. 06Document each event type so an operator knows what each failure category means.

Controls

  • When an automation or webhook quietly fails, leads stop syncing or emails stop sending and nobody notices until a client asks why they never heard...
  • A read-only dashboard over the monitoring_events table that counts and lists failure-type events (webhook errors, Turnstile failures, send failures...
  • When automation confidence is low, route the record to a manual owner with the source, stage, and last action attached.

Research basis