Waarom Ik CronGuard Bouwde (En Waarom Jij Het Nodig Hebt)

Van een nachtelijk database-incident tot een live SaaS product: hoe één failende cron job leidde tot CronGuard, en wat ik leerde tijdens het bouwen.

Jean-Pierre Broeders

Freelance DevOps Engineer

28 februari 20265 min. leestijd

Waarom Ik CronGuard Bouwde (En Waarom Jij Het Nodig Hebt)

Het was 3 uur 's nachts toen mijn telefoon ging. Een klant. Paniek in zijn stem. "De database backup van gisteren is corrupt. We hebben de backup van twee dagen geleden nodig, maar die ontbreekt ook. Wat is er gebeurd?"

Wat er gebeurd was? Een cron job die stil was gefaald. Geen error logs. Geen alerts. Gewoon... gestopt.

Het Probleem Dat Ik Bleef Tegenkomen

Als freelance DevOps engineer zie ik dit patroon constant:

  1. Team zet een cron job op voor iets kritisch (backups, facturen, data sync)
  2. Job draait prima... voor een tijdje
  3. Ergens gaat er iets mis (disk vol, API down, dependencies update)
  4. Niemand merkt het
  5. Dagen later: crisis

Het ergste? Het is altijd vermijdbaar geweest.

De waarheid is dat cron jobs de stille helden van je infrastructuur zijn — totdat ze de stille moordenaars worden.

Waarom Bestaande Tools Niet Werkten

Ik probeerde verschillende oplossingen:

Dead Man's Switch services — te basic. Ze checken alleen "heeft het gedraaid?", niet "is het geslaagd?"

Full monitoring stacks (Prometheus, Grafana, Datadog) — overkill. Ik wil geen hele observability platform opzetten om 5 cron jobs te monitoren.

Custom scripts — werken... tot je ze moet onderhouden. En debuggen. En documenteren. En delen met je team.

Wat ik nodig had was simpel:

  • Weet wanneer een job zou moeten draaien
  • Check of het echt draaide
  • Alert me als het faalt
  • Maak het makkelijk om te debuggen

De Geboorte van CronGuard

Ik bouwde CronGuard in een weekend. Nou ja, de MVP. De eerste versie kon:

  1. Unique URL per job — curl die URL aan het einde van je script
  2. Grace periods — als het job niet binnen X minuten checkt in, alarm
  3. Email alerts — simpel, effectief
  4. Dashboard — overzicht van alle jobs in één blik

Voorbeeld gebruik:

#!/bin/bash
# Je normale cron job
pg_dump mydb > backup.sql

# Check in bij CronGuard
curl -X POST https://cronguard.app/ping/abc123xyz

Zo simpel. Werkt altijd.

Wat Ik Leerde Bij Het Bouwen

1. Exit Codes Zijn Niet Genoeg

Veel monitoring tools checken alleen de exit code. Maar een script kan exit 0 geven terwijl het in werkelijkheid gefaald heeft:

#!/bin/bash
# Dit geeft altijd exit 0, ook als de backup faalt
pg_dump mydb > backup.sql
echo "Backup completed"  # exit 0

CronGuard's oplossing: Check niet alleen of het script draaide, maar of het op tijd incheckte. Als je script crasht vóór de curl, krijg je een alert.

2. Grace Periods Zijn Kritisch

Niet alle jobs duren even lang. Een backup van 10GB duurt langer dan één van 1GB. Met vaste timeouts krijg je false positives.

CronGuard's oplossing: Stel een grace period in per job. Het job mag variëren binnen die window voordat het als "te laat" wordt gemarkeerd.

3. Debugging Moet Makkelijk Zijn

Als een job faalt om 3 uur 's nachts, wil je niet door logs graven. Je wil zien:

  • Wanneer draaide het voor het laatst?
  • Wat was de output?
  • Hoeveel keer heeft het gefaald?

CronGuard's oplossing: Elk ping kan een status message meesturen:

curl -X POST https://cronguard.app/ping/abc123xyz \
  -d "Backup completed: 10.2GB, 47 tables"

Staat allemaal in het dashboard. Logs zonder de complexity.

4. Integraties Zijn Essentieel

Email alerts zijn prima, maar als je team in Slack werkt, wil je de alert daar zien.

CronGuard ondersteunt:

  • Email
  • Slack
  • Discord
  • Webhooks (voor custom integrations)
  • SMS (voor kritische jobs)

Real-World Use Cases

Na een paar maanden live te zijn, zie ik CronGuard gebruikt worden voor:

Scheduled backups — de oorspronkelijke use case. Database dumps, file backups, replicatie jobs.

Invoice generation — e-commerce sites die elke nacht facturen genereren en versturen.

Data synchronisatie — syncing tussen CRM, ERP, en andere business tools.

Report generation — wekelijkse/maandelijkse rapporten die naar management moeten.

Cleanup jobs — oude logs verwijderen, cache clearen, temp files opruimen.

Health checks — periodieke checks of externe APIs nog leven.

De Tech Stack (Voor De Nerds)

CronGuard draait op:

  • Next.js 15 (app router) voor de frontend + API routes
  • Neon (serverless Postgres) voor data storage
  • Clerk voor authentication
  • Vercel voor hosting
  • Resend voor email delivery

Waarom deze stack?

  1. Serverless = geen onderhoud — ik wil niet servers beheren
  2. Edge-ready — snelle response times wereldwijd
  3. Developer experience — bouwen moet fun zijn, niet pijnlijk
  4. Schaalbaar — van 10 jobs naar 10.000 zonder infrastructuur wijzigingen

Wat Het Kost (En Waarom)

Ik wilde CronGuard accessible maken, niet nog een dure enterprise tool.

Free tier:

  • Tot 5 jobs
  • Email alerts
  • 30 dagen history
  • Basic dashboard

Pro tier ($9/maand):

  • Unlimited jobs
  • Alle notification channels
  • 1 jaar history
  • Advanced analytics
  • Priority support

Geen verrassingen. Geen per-ping pricing. Gewoon simpel.

Lessons Learned Over SaaS Bouwen

Dit was mijn eerste echte SaaS product. Wat ik leerde:

Start Klein, Ship Snel

De eerste versie had geen fancy analytics, geen team features, geen API. Just: ping een URL, krijg alerts. Dat was genoeg om waarde te leveren.

Features kwamen later, gebaseerd op wat gebruikers echt vroegen.

Documentatie Is Marketing

Goede docs = minder support tickets + betere conversie. Ik schreef guides voor:

  • Elke populaire cron scheduler
  • Common use cases
  • Integration examples

Developers lezen docs. Maak ze goed.

Monitoring Je Monitoring Tool Is Meta

De ironie: CronGuard zelf draait cron jobs (alerts, cleanup, analytics). Dus ik gebruik... CronGuard om CronGuard te monitoren. Het werkt verrassend goed.

Waarom Je CronGuard Moet Proberen

Als je cron jobs draait die belangrijk zijn (en welke zijn dat niet?), heb je monitoring nodig.

Je kunt:

  1. Een custom oplossing bouwen (kosten: 10-20 uur + onderhoud)
  2. Een enterprise monitoring stack kopen (kosten: $100-500/maand)
  3. CronGuard gebruiken (kosten: gratis tot $9/maand)

Ik bouwde CronGuard omdat ik optie 3 wilde. Geen overkill, geen underkill. Just right.

Probeer het gratis: cronguard.app

Setup duurt letterlijk 2 minuten. Voeg één curl toe aan je script, en je bent klaar.

Wat Nu?

Ik werk aan:

  • Retry logic — automatisch retry bij transient failures
  • Team features — shared dashboards, role-based access
  • Terraform/Pulumi provider — infrastructure as code integratie
  • Status pages — public status page voor je jobs

Heb je feature requests? Suggesties? Laat het me weten.


CronGuard is live op cronguard.app. Gratis tier, geen credit card vereist. Setup in 2 minuten.

Wil je op de hoogte blijven?

Schrijf je in voor mijn nieuwsbrief of neem contact op voor freelance projecten.

Neem Contact Op