Forem: Domonique Luchin

Building a self-healing cron system with pg_cron and Supabase edge functions

Domonique Luchin — Mon, 11 May 2026 10:00:02 +0000

I run 6 AI businesses from a single VPS. When your entire operation depends on automated tasks running perfectly, you learn to build systems that fix themselves before you wake up to angry customers.

Here's how I built a cron system that monitors itself and recovers from failures automatically using pg_cron and Supabase Edge Functions.

Why I needed this

My Load Bearing Empire processes thousands of AI agent calls daily. Lead scoring runs every 15 minutes. Data sync happens hourly. Payment processing triggers every 30 minutes.

A single failed cron job costs me real money. I've been burned by silent failures too many times.

Most developers rely on external monitoring services. I prefer owning my infrastructure. This system costs me $0 in additional subscriptions and runs entirely within Supabase.

The architecture

Three components work together:

pg_cron schedules and executes jobs
Edge Functions handle the actual business logic
Health monitoring table tracks job status and triggers recovery

The key insight: every cron job reports its status to a central monitoring table. If a job fails or doesn't report in, the system automatically retries and alerts me.

Setting up the foundation

First, enable pg_cron in your Supabase project:

-- Run this in your SQL editor
CREATE EXTENSION IF NOT EXISTS pg_cron;

-- Create the monitoring table
CREATE TABLE cron_health (
  id SERIAL PRIMARY KEY,
  job_name TEXT NOT NULL,
  last_run TIMESTAMP WITH TIME ZONE,
  last_success TIMESTAMP WITH TIME ZONE,
  status TEXT CHECK (status IN ('running', 'success', 'failed')),
  error_message TEXT,
  retry_count INTEGER DEFAULT 0,
  created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

-- Index for fast lookups
CREATE INDEX idx_cron_health_job_name ON cron_health(job_name);
CREATE INDEX idx_cron_health_last_run ON cron_health(last_run);

Creating a self-reporting Edge Function

Here's an Edge Function that reports its own health status:

// supabase/functions/process-leads/index.ts
import { serve } from "https://deno.land/std@0.168.0/http/server.ts"
import { createClient } from 'https://esm.sh/@supabase/supabase-js@2'

serve(async (req) => {
  const jobName = 'process-leads'
  const supabase = createClient(
    Deno.env.get('SUPABASE_URL') ?? '',
    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY') ?? ''
  )

  try {
    // Update status to running
    await supabase
      .from('cron_health')
      .upsert({
        job_name: jobName,
        last_run: new Date().toISOString(),
        status: 'running',
        retry_count: 0
      }, { onConflict: 'job_name' })

    // Your actual business logic here
    const result = await processLeads()

    // Report success
    await supabase
      .from('cron_health')
      .upsert({
        job_name: jobName,
        last_run: new Date().toISOString(),
        last_success: new Date().toISOString(),
        status: 'success',
        error_message: null
      }, { onConflict: 'job_name' })

    return new Response(JSON.stringify({ success: true, processed: result.count }))

  } catch (error) {
    // Report failure
    await supabase
      .from('cron_health')
      .upsert({
        job_name: jobName,
        last_run: new Date().toISOString(),
        status: 'failed',
        error_message: error.message,
        retry_count: (await getCurrentRetryCount(jobName)) + 1
      }, { onConflict: 'job_name' })

    return new Response(JSON.stringify({ error: error.message }), { status: 500 })
  }
})

The self-healing mechanism

This monitoring function runs every 5 minutes and handles recovery:

-- Create the health check function
CREATE OR REPLACE FUNCTION check_cron_health()
RETURNS void AS $$
DECLARE
  job_record RECORD;
  function_url TEXT;
BEGIN
  -- Find jobs that haven't reported success in their expected interval
  FOR job_record IN 
    SELECT job_name, last_run, last_success, retry_count
    FROM cron_health
    WHERE (
      -- Jobs that should run every 15 minutes but haven't succeeded in 20 minutes
      (job_name LIKE '%leads%' AND last_success < NOW() - INTERVAL '20 minutes') OR
      -- Jobs that should run hourly but haven't succeeded in 75 minutes  
      (job_name LIKE '%sync%' AND last_success < NOW() - INTERVAL '75 minutes')
    )
    AND retry_count < 3
  LOOP
    -- Build the Edge Function URL
    function_url := 'https://your-project.supabase.co/functions/v1/' || job_record.job_name;

    -- Trigger retry via HTTP request
    PERFORM net.http_post(
      url := function_url,
      headers := '{"Authorization": "Bearer ' || current_setting('app.service_role_key') || '"}',
      body := '{}'
    );

    -- Log the retry attempt
    INSERT INTO cron_health (job_name, last_run, status, retry_count)
    VALUES (job_record.job_name || '_retry', NOW(), 'retry_triggered', job_record.retry_count + 1);

  END LOOP;
END;
$$ LANGUAGE plpgsql;

Scheduling everything

Now wire it all together with pg_cron:

-- Schedule your business logic
SELECT cron.schedule('process-leads', '*/15 * * * *', 
  'SELECT net.http_post(''https://your-project.supabase.co/functions/v1/process-leads'', ''{"Authorization": "Bearer service_role_key"}'', '''')');

-- Schedule the health monitor
SELECT cron.schedule('health-check', '*/5 * * * *', 'SELECT check_cron_health()');

-- Clean up old health records weekly
SELECT cron.schedule('cleanup-health', '0 2 * * 0', 
  'DELETE FROM cron_health WHERE created_at < NOW() - INTERVAL ''30 days''');

Monitoring dashboard

Query this to see your system health:

-- Current status of all jobs
SELECT 
  job_name,
  status,
  last_success,
  EXTRACT(EPOCH FROM (NOW() - last_success))/60 as minutes_since_success,
  retry_count,
  error_message
FROM cron_health 
WHERE job_name NOT LIKE '%retry%'
ORDER BY last_run DESC;

Real results

Since implementing this system 3 months ago:

Zero silent failures
4 automatic recoveries from network timeouts
99.8% job success rate
2 minutes average recovery time

You get infrastructure that fixes itself. Your cron jobs report their health. Failed jobs retry automatically. You sleep better knowing your systems won't fail silently.

Build systems that work without you watching them.

Why I Own My Telecom Stack Instead of Paying $200/Month for VoIP SaaS

Domonique Luchin — Fri, 08 May 2026 10:00:02 +0000

Business phone systems are a tax on not knowing how VoIP works.

I stopped paying it.

What the Market Charges

Grasshopper: $49/month for 1 number, 3 extensions
RingCentral: $99/month per user
Dialpad: $75/month per user
Google Voice for Business: $30/month per user

For six business lines with AI voice agents, I would spend $200 to $500 every month depending on the plan.

What I Actually Pay

$29.70 per month. Six lines. AI on every one.

Breakdown:

VoIP.ms DIDs: 6 x $4.95 = $29.70/month
Asterisk: free, runs on a VPS I already own
VAPI: usage-based, low volume in early stage

What I Own vs What I Rent

With SaaS I rent access. If they raise prices, change terms, or shut down, I lose the system.

With Asterisk + VoIP.ms I own the PBX configuration, own the SIP trunk relationship, and can move providers without rebuilding anything.

The Infrastructure Sovereignty Principle

I apply five rules to every service in my stack:

Multi-model abstracted — no single vendor lock-in
Logged to Supabase in real time
Self-hosted equivalent exists for every managed service
Contingency defined before going live
All data, prompts, and outputs are mine

Telecom is not special. The same logic applies. Own the stack or pay the tax forever.

Is It Hard?

Asterisk has a learning curve. VoIP.ms requires KYC. PJSIP configuration takes a few hours to get right.

After that, it runs without touching it. That is the trade. A few hard hours once, or $200 every month forever.

From Gulf Coast Pipe Racks to AI Agent Orchestration: The Engineer's Path

Domonique Luchin — Thu, 07 May 2026 10:00:02 +0000

I spent six years designing pipe racks and equipment platforms for Gulf Coast oil and gas facilities.

Now I also build AI agent systems that run six businesses.

These two things are not as different as they sound.

Structural Engineering as a Mental Model

Structural engineering teaches you to think in systems. Every element has a load path. Every load path has a failure mode. You design for the failure mode before you design for the load.

AI agent architecture works the same way.

Every agent has an input path. Every input path has a failure mode — hallucination, timeout, bad routing, context loss. You design the guardrails before you design the workflow.

What Engineering Gave Me

Tolerance for specification-heavy documentation
Comfort with systems that have real consequences if they fail
Habit of verifying assumptions before building
Understanding that complexity compounds — keep it simple at the component level

All four apply directly to building production AI systems.

The Translation

Engineering Concept	AI Equivalent
Load path	Data flow between agents
Failure mode	Hallucination or routing error
Code reference (AISC, ACI)	LLM system prompt constraints
Shop drawings	Agent tool schemas
RFI	Human approval gate
Punch list	Audit agent output

The Path

I did not leave engineering to build software. I layered software on top of engineering.

The job funds the empire build. The empire builds the exit. The engineering knowledge makes both more defensible.

You do not need to choose between technical depth and building businesses. The technical depth is the competitive advantage.

Self-Hosted vs Managed: The Real Cost Breakdown After 6 Months

Domonique Luchin — Wed, 06 May 2026 10:00:02 +0000

I run six businesses on a single $24/month VPS.

Here is what that actually costs compared to the managed alternative.

My Stack vs the SaaS Equivalent

Function	What I Use	Monthly Cost	SaaS Equivalent	SaaS Cost
Phone system	Asterisk + VoIP.ms	$29.70	RingCentral	$99/user
Database	Supabase (free tier)	$0	PlanetScale	$39
AI agents	VAPI + Claude API	Usage	Bland AI	$150+
Content pipeline	Custom pg_cron + Edge Functions	$0	Buffer Pro	$100
Lead scraping	CrawlOS on VPS	$0	BatchLeads	$299
Credit dispute automation	Custom FCRA engine	$0	DisputeBee	$69
Server	Vultr VPS (4 vCPU / 8 GB)	$24	N/A	N/A

My total: ~$75/month

SaaS equivalent: ~$800/month

The Hidden Costs of Self-Hosting

Being honest here. Self-hosting is not free.

Time to build: 200+ hours over 6 months
Time to maintain: 3 to 5 hours per week
Debugging cost: High at first, drops significantly after 60 days

The Break-Even

At $725/month savings, the build time pays off in the first month at a $50/hour rate.

After month one, it is pure margin.

Who This Makes Sense For

If you can build it, own it. If you cannot build it and cannot learn to, pay for it.

The math only works if the self-hosted version actually runs reliably. A broken self-hosted stack is worse than SaaS — you pay in time and still do not get the output.

Build it right the first time. Then own it forever.

County Record Scraping: How CrawlOS Finds 125 Leads Per Night Across 14 Texas Counties

Domonique Luchin — Tue, 05 May 2026 10:00:02 +0000

Every night while I sleep, a Playwright scraper hits 14 Texas county deed record portals and logs 125 qualified leads to my CRM.

Here is how CrawlOS works.

The Problem With Paid Data

Real estate lead services charge $200 to $500 per month for the same public data that county appraisal districts publish for free.

I built a scraper instead.

The Architecture

CrawlOS is a Python + Playwright system running on lb-telecom-01 (my Vultr VPS in Dallas).

It hits the public-facing portal for each county, extracts recent deed filings, filters by acquisition criteria, and inserts qualifying records into a Supabase table.

The 14 Counties

Harris, Fort Bend, Montgomery, Brazoria, Galveston, Chambers, Liberty, Waller, Austin, Colorado, Wharton, Matagorda, Jackson, and Victoria.

All Gulf Coast and surrounding markets — the territory I know from six years of O&G structural work in the region.

The Filter Logic

Not every deed transfer is a lead. The scraper applies filters:

Transfer type: warranty deed, not quitclaim
Price range: within acquisition parameters
Property type: residential or light commercial
Recency: filed within the last 30 days

Anything passing all four filters gets inserted. Everything else is discarded.

The Output

125 leads per night on average. Each record includes parcel ID, grantor/grantee, transfer amount, address, and filing date.

Load Bearing Capital works the list. Petroleum Noir runs a parallel filter on mineral rights transfers from the same pipeline.

Why This Matters

The data is public. It has always been public. The advantage is not access — it is automation.

Anyone can pull Harris County deed records manually. Almost nobody does it every night across 14 counties without lifting a finger.

Building Load Bearing Empire From Your Phone During Off Hours

Domonique Luchin — Tue, 05 May 2026 01:30:29 +0000

I do not have a home office setup. I work from my phone.

Here is how I run six AI businesses after a full day of structural engineering.

The Constraint

I work 8 to 10 hours a day as a Lead Structural Engineer. When I get home I am tired. I do not have the energy to sit at a desk for three more hours.

So I do not. I work from my couch, from my bed, during lunch breaks.

What Makes It Possible

Automation handles the volume. I handle the decisions.

My systems run nightly jobs, generate leads, draft content, and answer phones without me. I review outputs, approve or reject, and move on.

The decision layer is the only part that requires my brain. I have compressed that to 30 to 60 minutes per night.

The Tools

Claude on mobile — architecture, writing, strategy, debugging
Supabase dashboard — checking table data, reviewing queue status
Termius — SSH into lb-telecom-01 when something needs a direct fix
Vercel — deployment monitoring

The Workflow

Check JARVIS memory table for overnight activity
Review content queue — approve or reject pending posts
Check lead pipeline — flag anything needing manual follow-up
One new build decision per night — what gets worked on next

That is it. Thirty minutes. Everything else runs itself.

The Real Skill

The skill is not technical. It is designing systems that do not require you.

Every time I build something, I ask: what happens when I do not touch this for two weeks? If the answer is "it breaks," I have not built a system. I have built a job.

Build systems, not jobs.

Building Load Bearing Empire From Your Phone During Off Hours

Domonique Luchin — Tue, 05 May 2026 01:30:29 +0000

I do not have a home office setup. I work from my phone.

Here is how I run six AI businesses after a full day of structural engineering.

The Constraint

I work 8 to 10 hours a day as a Lead Structural Engineer. When I get home I am tired. I do not have the energy to sit at a desk for three more hours.

So I do not. I work from my couch, from my bed, during lunch breaks.

What Makes It Possible

Automation handles the volume. I handle the decisions.

My systems run nightly jobs, generate leads, draft content, and answer phones without me. I review outputs, approve or reject, and move on.

The decision layer is the only part that requires my brain. I have compressed that to 30 to 60 minutes per night.

The Tools

Claude on mobile — architecture, writing, strategy, debugging
Supabase dashboard — checking table data, reviewing queue status
Termius — SSH into lb-telecom-01 when something needs a direct fix
Vercel — deployment monitoring

The Workflow

Check JARVIS memory table for overnight activity
Review content queue — approve or reject pending posts
Check lead pipeline — flag anything needing manual follow-up
One new build decision per night — what gets worked on next

That is it. Thirty minutes. Everything else runs itself.

The Real Skill

The skill is not technical. It is designing systems that do not require you.

Every time I build something, I ask: what happens when I do not touch this for two weeks? If the answer is "it breaks," I have not built a system. I have built a job.

Build systems, not jobs.

Building Load Bearing Empire From Your Phone During Off Hours

Domonique Luchin — Tue, 05 May 2026 01:30:29 +0000

I do not have a home office setup. I work from my phone.

Here is how I run six AI businesses after a full day of structural engineering.

The Constraint

I work 8 to 10 hours a day as a Lead Structural Engineer. When I get home I am tired. I do not have the energy to sit at a desk for three more hours.

So I do not. I work from my couch, from my bed, during lunch breaks.

What Makes It Possible

Automation handles the volume. I handle the decisions.

My systems run nightly jobs, generate leads, draft content, and answer phones without me. I review outputs, approve or reject, and move on.

The decision layer is the only part that requires my brain. I have compressed that to 30 to 60 minutes per night.

The Tools

Claude on mobile — architecture, writing, strategy, debugging
Supabase dashboard — checking table data, reviewing queue status
Termius — SSH into lb-telecom-01 when something needs a direct fix
Vercel — deployment monitoring

The Workflow

Check JARVIS memory table for overnight activity
Review content queue — approve or reject pending posts
Check lead pipeline — flag anything needing manual follow-up
One new build decision per night — what gets worked on next

That is it. Thirty minutes. Everything else runs itself.

The Real Skill

The skill is not technical. It is designing systems that do not require you.

Every time I build something, I ask: what happens when I do not touch this for two weeks? If the answer is "it breaks," I have not built a system. I have built a job.

Build systems, not jobs.

The pg_cron Bug That Silently Killed My Content Pipeline for Weeks

Domonique Luchin — Tue, 05 May 2026 01:30:27 +0000

For weeks my content pipeline was running. Zero posts were going out. No errors in the logs.

Here is what happened.

The Setup

I use pg_cron on Supabase to schedule content jobs. A cron job fires every hour, calls an edge function, and the function posts queued articles to dev.to.

Simple enough.

The Symptom

Articles were sitting in the queue with status ready. The cron job showed successful execution in cron.job_run_details. The edge function showed 200 responses.

Nothing was posting.

The Root Cause

The edge function was calling the dev.to API with an Authorization header formatted as:

Authorization: api_key YOUR_KEY

Dev.to expects:

api-key: YOUR_KEY

The header name was wrong. The API returned a 401. The edge function caught the error, logged it to a column I was not monitoring, and returned 200 to pg_cron anyway.

The job looked healthy. The posts never went out.

The Fix

Correct the header. Add explicit error surfacing so a failed post sets status to error and writes the response body to error_message.

UPDATE build_content_queue 
SET status = 'error', error_message = $1 
WHERE id = $2;

What I Changed Going Forward

Never trust a 200 from your own wrapper. Inspect the downstream response code.
Write failures visibly — status column, not just a log.
Add a daily alert if zero posts go out in a 24-hour window.

Silent failures are the worst kind. They look like everything is working until you check the actual output.

How StructCalc AI Helped Me Land a Structural Engineering Role

Domonique Luchin — Tue, 05 May 2026 01:29:51 +0000

StructCalc AI is a structural engineering calculation platform I built from scratch.

It is also the project that made my ESI interview concrete.

What It Is

StructCalc AI is a full-stack application with 25 pages and 15 calculation engines covering:

AISC 360-22 steel design
ACI 318-19 concrete design
ASCE 7-22 load combinations and wind/seismic

Frontend: React + Vite deployed on Vercel. Backend: FastAPI on Railway. Database: Supabase.

Live at structcalc-ai.vercel.app.

Why I Built It

I was tired of paying for structural software licenses I only used occasionally. I wanted a web-based tool I could open on any device.

So I built it.

What It Does

19 verified API endpoints. Calculations for beam bending, column buckling, connection design, load takedowns, and more. The AI layer walks you through inputs and flags code non-compliance.

How It Helped in the Interview

When ESI asked about my technical background, I did not just list experience. I pointed to a live production application that implemented the same code references I use daily.

Building the tool forced me to re-derive every equation from the specification. You cannot fake that level of understanding in an interview.

The Bigger Point

If you are an engineer trying to stand out — build something. Not a resume bullet. A working application.

The market is full of engineers with 10 years of experience and nothing to show outside a PDF. Build one real thing and you separate yourself immediately.

CLAWKILLER: My 8-Agent LangGraph Autonomous Ops Platform

Domonique Luchin — Tue, 05 May 2026 01:29:15 +0000

CLAWKILLER is the name I gave my AI orchestration system.

It runs six businesses from a single server. Here is the architecture.

Why I Built It

I could not afford to context-switch between six companies during a full-time engineering job. I needed a system that could intake a goal, plan execution, use tools, and complete the task without me sitting there.

LangGraph gave me the graph-based agent orchestration I needed. Supabase gave me persistent memory. Claude and GPT-4o gave me the reasoning layer.

The 8 Agents

SUPERVISOR — Command parser and router. Every task enters here first. Routes to the appropriate specialist agent based on intent.

BROWSER — Playwright-powered web agent. Account creation, form fills, web scraping, social posting.

CONTENT — Writes articles, captions, scripts. Pulls from session logs and build notes.

COMMS — Drafts emails, SMS, and Slack messages. Handles follow-ups and outreach sequences.

DATA — Queries Supabase, runs reports, pulls lead pipeline status across all six companies.

SCRAPER — Nightly lead generation. Hits county deed records, filters by acquisition criteria, logs to CRM tables.

SCHEDULER — Creates calendar events, queues time-sensitive tasks, manages approval gates.

AUDIT — Reviews completed tasks for errors, logs anomalies, surfaces issues requiring human review.

Memory Architecture

Every agent writes state to Supabase after each step. Session continuity does not depend on keeping a single process alive.

The jarvis_memory table stores intent, execution history, tool results, and status. Any agent can query it to pick up where another left off.

Control Plane vs Intelligence Layer

CLAWKILLER is the control plane. Claude and GPT-4o are the intelligence layer.

CLAWKILLER decides what runs and when. The LLMs decide how.

Current Status

Schema live on Supabase (project: whxtjboruayowkqyjvcq). Services running on lb-telecom-01 ports 8000, 3001, and 3000. Claude Code installed for dispatch via the claude_code_queue table.

This is not a demo project. It runs production workloads every night.

How I Built a Self-Hosted PBX With Asterisk and VAPI for 6 Business Phone Lines

Domonique Luchin — Tue, 05 May 2026 01:28:39 +0000

Six businesses. Six phone numbers. One server. Zero monthly phone system fees.

Here is exactly how I built it.

The Problem

Every business needs a phone line. Business phone systems charge $30 to $80 per line per month. For six lines that is $180 to $480 every month just to receive calls.

I refused to pay that.

The Stack

Asterisk 18.10 — open-source PBX running on lb-telecom-01 (Vultr Dallas VPS at 45.32.198.24)
VoIP.ms — SIP trunk provider, KYC approved, six 832-area-code DIDs at $4.95/month each
VAPI — AI voice agent layer sitting in front of Asterisk

Total monthly cost: $29.70 for six lines. Not per line. Total.

The DIDs

Six numbers provisioned on Flat Rate through dallas1.voip.ms:

1315 — Load Bearing Capital
1316 — Load Bearing Demo
1317 — Quiet Hours Valet
1318 — Luchin Credit Repair
1319 — Petroleum Noir
1321 — Load Bearing Detailing

How VAPI Connects

VAPI sits as the public-facing layer. Calls come in, VAPI answers with a brand-specific AI voice agent, qualifies the caller, and routes or logs based on intent.

Asteisk handles the SIP registration and trunk. VAPI handles the intelligence.

The PJSIP trunk is registered to account 528502 on VoIP.ms.

What This Replaced

Grasshoppa: $49/month. RingCentral: $99/month. Dialpad: $75/month.

I pay $29.70 and own the entire stack.

Build It Yourself

Spin a VPS (Vultr or Linode, 1 vCPU / 1 GB RAM is enough)
Install Asterisk 18 from source
Create a VoIP.ms account, complete KYC, provision DIDs on Flat Rate
Configure PJSIP trunk in Asterisk pointing to your VoIP.ms account
Register your VAPI agents to the SIP endpoint
Test inbound call flow per DID

If you want AI on the phones, VAPI is the fastest path. If you want pure routing only, Asterisk dialplan handles it natively.