I run Jarvis, a personal AI operations system built on Claude, running a stack of Python scripts, cron jobs, and API integrations across Telegram, Gmail, Substack, WHOOP, and a half-dozen social platforms.
For the past two weeks, it has been breaking in the most frustrating way possible: silently.
No error. No alert. No failed process showing up in logs. Just... nothing happening. The morning brief doesn't arrive. The reminders stop. The reports go quiet. And I'm left staring at my screen wondering if I forgot to turn something on or if the whole thing collapsed while I was asleep.
Here is what I found.
The Silent Cron Death Problem on Mac
The core infrastructure bug: cron jobs on a MacBook are not always-on automations. They are "when the lid is open and the network is alive" automations.
When you:
• Close the laptop lid
• Switch WiFi networks (hotel → hotel, office → café)
• Let the machine sleep
...cron jobs don't fail with an error. They simply don't run. There's no retry queue. No failure notification. No logged exception. The job is skipped and the scheduler moves on like nothing happened.
This is not a code problem. It's an infrastructure mismatch. If you're building automations that need to fire reliably at 7am every day, a laptop-hosted cron is the wrong tool, regardless of how clean your Python is.
Real fix: Migrate to a VPS or VM. I'm in the process of doing this now. My migration order:
- Stateless reporting jobs first: sleep brief, news digest, WHOOP summary. No human input needed, low blast radius if they hiccup once during migration.
- Stateful jobs second: weekly article posting, social media reporting. These write state files and need more careful cutover.
- Interactive jobs last: anything that requires Telegram approval (email gate, send confirmations). These need the full environment stable before touching them.
The rule: migrate lowest risk → highest risk. Never everything at once.
The Build vs. Execute Role Split
A secondary lesson that cost me more time than I want to admit:
Don't use your execution-layer AI to build your pipelines.
I was using Jarvis (my automation runner) to also write and modify the scripts it runs. That creates compounding fragility, the system you're depending on to be stable is also the system modifying itself.
The cleaner architecture:
Build layer: Claude Code / Cursor / AG (Antigravity)
→ writes pipelines, fixes bugs, audits architecture
Execute layer: Jarvis (Claude via OpenClaw)
→ runs pre-built pipelines, routes tasks, manages I/O
Keeping these two roles separate means: if the build layer makes a mistake, the execute layer is unaffected. If the execute layer hiccups, you're not rewriting code mid-incident.
It's the same principle as not having your CI/CD pipeline deploy itself.
The 70/80 Rule for Real AI Operations
Stop trying to automate 100% of your operation.
For reference, here's where I landed after two weeks of breaking and rebuilding:
• ~75% of daily operations handled by automated pipelines
• ~15% handled by Jarvis on request (drafts, research, summaries)
• ~10% always done by me (financial decisions, client context, strategic pivots)
That last 10% is not a failure of automation. It's where my actual judgment lives. The ROI on trying to automate that 10% is negative, you will spend more time building guardrails than you save on execution.
The founders who win the agent era aren't the ones who automate the most. They're the ones who correctly identify what still needs them, and protect that time.
What's the hardest infrastructure decision you've hit running AI pipelines? Mac vs VPS, cron vs queue, single-agent vs multi-agent, drop the specific problem in the comments.
Top comments (0)