3 Cron Job Wajib untuk Agentic AI di VPS

Agentic AI yang serius itu bukan cuma chatbot yang bisa jawab pertanyaan.

Kalau dia jalan 24/7 di VPS, connect ke Telegram, baca file, pakai tools, panggil model AI, dan punya jadwal kerja sendiri, maka dia sudah masuk wilayah production system.

Dan production system yang tidak punya monitoring itu bukan production. Itu cuma berharap semoga tidak rusak.

Agak goblok kalau kita bikin AI agent yang bisa menjalankan banyak hal, tapi dia sendiri tidak tahu kalau disk penuh, gateway mati, model provider auth error, atau Telegram bot berhenti menerima pesan.

Makanya menurutku ada tiga cron job minimum yang wajib ada di setiap VPS yang menjalankan AI agent seperti Hermes, OpenClaw, atau personal assistant sejenis:

1. VPS Health Watchdog
2. Gateway Self-Healing
3. Model / Provider Health Check

Tiga ini sederhana. Tidak sexy. Tapi justru ini yang bikin agentic AI terasa seperti operator beneran, bukan demo yang rapuh.

Kenapa agentic AI harus preemptive?

Karena user tidak boleh jadi monitoring system.

Kalau user baru sadar AI agent mati setelah bertanya dan tidak dibalas, berarti desainnya kalah. Kalau user baru tahu model provider error setelah semua automation gagal, berarti sistemnya belum dewasa. Kalau user baru sadar disk penuh setelah deploy gagal, itu bukan incident response. Itu telat.

Agentic AI harus punya pola kerja seperti ini:

• observe: cek kondisi sistem secara rutin,
• decide: bedakan normal, warning, degraded, critical,
• act: lakukan tindakan aman yang reversible,
• notify: kabari manusia hanya kalau perlu,
• record: simpan log supaya bisa diaudit.

Itu baru agentic.

Bukan karena AI-nya sok mandiri. Tapi karena kerja ops memang banyak yang bisa diprevent sebelum jadi masalah besar.

1. VPS Health Watchdog

Cron pertama adalah health watchdog untuk VPS.

Tugasnya sederhana: cek apakah rumah tempat AI agent tinggal masih sehat.

Minimal cek:

• disk usage,
• RAM usage,
• CPU load,
• service penting,
• gateway process,
• Telegram channel,
• SSL/domain expiry.

Trigger yang masuk akal:

• disk di atas 80%,
• RAM di atas 85%,
• CPU load abnormal dibanding jumlah core,
• gateway mati atau restart loop,
• Telegram webhook/polling error,
• SSL hampir expired.

Output-nya jangan spam.

Ini penting: watchdog yang kirim pesan tiap 30 menit walaupun semua normal itu bukan monitoring. Itu noise generator.

Yang benar:

Every 30-60 minutes:
  check VPS health
  if everything OK:
    stay silent
  if warning/critical:
    send Telegram alert
  write latest state to file

Untuk AI agent, silent success itu fitur.

Manusia tidak perlu tahu setiap kali CPU 12%. Manusia perlu tahu kalau disk 86%, RAM 91%, atau SSL tinggal 9 hari.

2. Gateway Self-Healing

Cron kedua adalah self-healing untuk gateway.

Gateway adalah jantung AI agent. Kalau gateway mati, Telegram bisa diam, tools tidak jalan, scheduler gagal, dan agent terlihat seperti sedang tidur padahal sebenarnya crash.

Self-healing minimal jalan tiap 10-15 menit.

Flow-nya begini:

Every 10-15 minutes:
  check gateway service
  if active:
    do nothing
  if down:
    restart gateway
    wait a few seconds
    verify health endpoint
    if recovered:
      send recovery report
    if still down:
      send critical alert

Yang perlu dijaga: jangan restart membabi buta.

Harus ada restart limit. Misalnya maksimal 3 percobaan dalam 15 menit. Kalau sudah lewat batas, berhenti restart dan escalate ke manusia.

Kenapa?

Karena restart loop bisa menutupi root cause. Kalau config salah, token expired, port conflict, atau database locked, restart terus-menerus cuma bikin log makin berisik.

Self-healing yang bagus bukan berarti selalu berhasil memperbaiki. Self-healing yang bagus berarti:

• coba recovery aman,
• verifikasi hasil,
• tahu kapan harus berhenti,
• kasih laporan yang jelas.

3. Model / Provider Health Check

Ini bagian yang sering dilupakan.

AI agent production tidak cuma bergantung ke VPS. Dia juga bergantung ke model provider.

Kalau provider utama rate limited, fallback auth error, quota habis, atau latency naik parah, agent bisa terlihat hidup tapi kualitas kerjanya turun drastis.

Ini lebih tricky daripada server down.

Server down biasanya jelas. Model provider degraded kadang kelihatan seperti agent lemot, jawab aneh, tool call gagal, atau cron task tiba-tiba error.

Health check model harus cek:

• provider utama jalan atau tidak,
• fallback jalan atau tidak,
• latency normal atau terlalu lambat,
• auth error,
• quota atau rate limit,
• timeout atau upstream error.

Pattern yang aku suka:

Every few hours:
  read configured primary model + fallbacks
  send tiny health prompt to each provider
  measure latency
  classify result:
    OK
    slow
    auth error
    quota/rate limit
    upstream timeout
  if primary broken but fallback OK:
    status = degraded
  if all broken:
    status = critical
  alert only on degraded/critical/recovered

Ini bukan cuma monitoring. Ini resilience map.

Kita jadi tahu apakah agent masih punya jalur fallback kalau provider utama bermasalah.

Contoh nyata: primary masih OK, tapi 9 fallback auth error. Sistem masih usable, tapi resilience-nya turun. Itu statusnya bukan healthy. Itu degraded.

Dan degraded harus diketahui sebelum primary ikut mati.

Kenapa tiga cron ini harus dipisah?

Karena failure mode-nya beda.

VPS Health Watchdog menjawab:

Apakah mesin tempat agent hidup masih sehat?

Gateway Self-Healing menjawab:

Apakah otak/runtime agent masih menyala, dan bisa direstart aman kalau mati?

Model / Provider Health Check menjawab:

Apakah agent masih punya akses ke model AI yang dibutuhkan untuk berpikir dan bekerja?

Kalau digabung semua jadi satu script raksasa, troubleshooting jadi ribet. Lebih baik kecil, spesifik, dan gampang diaudit.

Ini prinsip ops klasik: one job, one responsibility.

AI agent boleh pintar. Cron job tetap harus boring.

Alert yang baik itu seperti apa?

Alert harus actionable.

Alert buruk:

Error occurred.

Alert yang lumayan:

Gateway down.

Alert yang benar:

OpenClaw gateway down on VM-8-156.
Auto-restart attempted: failed.
Health endpoint: 000.
Last 3 checks failed.
Action: inspect journalctl --user -u openclaw-gateway.service

Untuk Telegram, jangan terlalu panjang. Tapi harus ada:

• apa yang rusak,
• severity,
• host,
• waktu,
• auto-action yang sudah dicoba,
• status recovery,
• next action.

Dan yang paling penting: jangan kirim kalau tidak ada masalah.

AI assistant yang proactive bukan berarti cerewet. Proactive berarti tahu kapan harus diam dan kapan harus membangunkan manusia.

Guardrail: jangan semua dibuat auto-fix

Ini bagian yang harus tegas.

Tidak semua issue boleh di-auto-heal.

Aman untuk auto-fix:

• restart service yang jelas mati,
• rotate log,
• clear cache yang memang disposable,
• retry endpoint check,
• restart gateway dengan limit.

Tidak aman untuk auto-fix tanpa approval:

• hapus file besar secara massal,
• edit config model/provider,
• rotate API key,
• force push repo,
• upgrade package major version,
• ubah firewall atau SSH access.

Agentic AI yang bagus bukan AI yang nekat. Agentic AI yang bagus tahu batas.

Dia boleh memperbaiki masalah kecil. Untuk tindakan berisiko, dia harus melapor dengan opsi yang jelas.

Bentuk minimum yang sudah cukup production

Kalau mau pragmatic, minimum setup-nya begini:

*/30 * * * * vps-health-watchdog.sh
*/10 * * * * gateway-self-heal.sh
17 */3 * * * model-provider-health-check.py

Dengan aturan:

• semua script punya log,
• semua script punya state file,
• alert pakai cooldown,
• success silent,
• failure classified,
• recovery notification dikirim,
• ada manual command untuk dry-run.

Dry-run penting karena script monitoring juga bisa salah.

Sebelum dipercaya, jalankan manual dulu. Cek output. Cek log. Cek apakah alert beneran sampai. Jangan cuma install cron lalu bilang done. Itu cara tercepat bikin silent failure yang ironis banget: monitoring-nya sendiri tidak termonitor.

Agentic AI bukan cuma bisa kerja, tapi bisa menjaga kerjaannya

Menurutku ini pembeda antara AI demo dan AI assistant yang beneran berguna.

Demo AI fokus ke prompt:

Lihat, dia bisa jawab.

Production AI fokus ke reliability:

Kalau dia gagal, dia tahu. Kalau bisa recovery, dia recovery. Kalau tidak bisa, dia notify user dengan konteks yang cukup.

Itu yang bikin user percaya.

Bukan karena AI-nya sempurna. Justru karena sistemnya mengakui bahwa AI, VPS, provider, API, dan network bisa gagal kapan saja.

Agentic AI yang matang harus punya mental model ops:

• preemptive action,
• safe self-healing,
• alert only when needed,
• audit trail,
• human escalation.

Tiga cron job ini kelihatannya kecil. Tapi efeknya besar.

Karena begitu AI agent mulai menjaga dirinya sendiri, dia bukan lagi chatbot yang menunggu perintah.

Dia sudah mulai jadi operator.

FAQ

Apakah health watchdog harus jalan tiap menit?

Tidak selalu. Untuk resource seperti disk, RAM, CPU, 30-60 menit biasanya cukup. Untuk service critical seperti gateway atau Telegram bot, 1-15 menit lebih masuk akal tergantung kebutuhan.

Apakah self-healing berbahaya?

Bisa berbahaya kalau tidak ada limit. Restart service dengan batas percobaan masih aman. Tapi auto-edit config, auto-upgrade, atau auto-delete file tanpa approval itu ide buruk.

Kenapa model provider perlu dicek terpisah?

Karena agent bisa terlihat hidup walaupun provider AI bermasalah. Gateway aktif, Telegram aktif, tapi model kena quota atau auth error. Tanpa provider check, masalah ini baru ketahuan saat task gagal.

Apa alert harus dikirim setiap check?

Tidak. Alert harus dikirim saat status berubah, saat critical berulang melewati cooldown, atau saat recovery. Kalau semua normal, diam.

Kesimpulan

Agentic AI yang jalan di VPS harus diperlakukan seperti sistem production.

Bukan cuma ditanya bisa jawab apa. Tapi dicek: kalau dia rusak, siapa yang tahu? Kalau gateway mati, siapa yang restart? Kalau provider error, siapa yang deteksi? Kalau disk hampir penuh, siapa yang membangunkan user sebelum semuanya gagal?

Jawaban minimalnya: tiga cron job.

Health Watchdog. Gateway Self-Healing. Model Provider Check.

Simple. Boring. Tapi justru itu fondasi yang bikin AI agent layak dipercaya.