How we run a 15-minute health-check SOP on autopilot with Kanban cron cards

If you've ever tried to babysit a "lightweight" health check — the kind where a cron job hits an endpoint, checks a few thresholds, decides whether to page someone, and then notes what it found for later trend analysis — you know it's never actually lightweight. You end up writing a glue script, wiring it to systemd or a cloud scheduler, building a dead-letter table, setting up an alerting channel, and then writing a runbook so the next on-caller knows what "yellow means but not red" translates to.

At EClaw, we've been running our public rental-fleet monitor on that kind of SOP for the last two weeks. Except we didn't write any of the glue. We wrote a kanban card, ticked "enable recurring schedule", and pasted the SOP into the description. Every 15 minutes, the card copies itself into the todo column, an operator (human or bot) picks it up, runs the SOP, posts the outcome as a card comment, appends a one-line snapshot to a mission note, and moves the card to done. That's it.

What the card actually looks like

Title: 🩺 [自動] 廣場 rental 健康巡檢 — 每 15 分鐘
Schedule: recurring, */15 * * * *, Asia/Taipei
Assigned: entity #2 (commander)

Description (SOP):
  Step 1 — Fetch /api/monitoring/rental-health
  Step 2 — Branch on thresholds.status:
    • green  → [SILENT], done.
    • yellow → Post "⚠️ yellow: <issues>" as card comment. No page.
    • red    → Post "🚨 red: <issues>"; speakTo #0 and #2.
  Step 3 — Regardless of color, append a line to the
           rental-health-history mission note.

Three steps. Each step is a concrete API call. The cron trigger handles the "every 15 minutes" part natively (it's a field on the card, not a cron service sitting somewhere else). And because the parent card lives on the same board as the rest of our work, if the SOP evolves — say we add a fourth threshold, or we start pinging a different Slack equivalent — we just edit the card description. No redeploy, no YAML migration.

The rolling snapshot pattern

Step 3 is the part we didn't expect to need but now can't live without. Each run appends one line to a shared rental-health-history note:

2026-04-20T02:50:13Z | status=yellow | db=14ms | listings=9 | contracts=0 | trash=582 | tomb=582 | issues=[publisher_disconnected:wordpress]
2026-04-20T03:05:07Z | status=yellow | db=2ms  | listings=9 | contracts=0 | trash=605 | tomb=605 | issues=[publisher_disconnected:wordpress]

It's not a dashboard. It's not a time-series DB. It's a text file that happens to be queryable via GET /api/mission/dashboard, which means bots and humans read it the same way. You can grep it for status=red, you can pipe it through awk to chart db latency, you can paste the last ten lines into a card comment when a reviewer asks "what was the trend?" The point isn't that it's fancy. The point is that the person (or bot) responding to an incident has a forensic trail that was written by the same SOP they're about to run, in a format they already know how to read.

Why Kanban beats a cron.d line for this

The first version of this check was a GitHub Actions workflow. It fired every 15 minutes, hit the endpoint, and posted to a Slack-equivalent channel if things were bad. That version ran for three days before we rewrote it as a kanban card. Three things went wrong:

1. No provenance on a silent green. Actions that succeed leave no artifact. When the fleet went yellow Friday afternoon, nobody could answer "when did this start?" without digging through workflow run history.
2. The SOP drifted from the runbook. The actual alert logic lived in YAML; the runbook lived in a README. By day two, they disagreed about what "yellow" meant.
3. No handoff surface. When a bot detects yellow, what does it do? It needs somewhere to leave a message for the next operator. A workflow has no inbox. A kanban card does.

The kanban version solves all three by construction: every run creates a visible card in done with its outcome attached, the SOP and the execution live in the same description, and card comments are the handoff inbox.

Try it

If you want to try this pattern on your own EClaw deployment, here's the curl to create the card:

curl -s -X POST "https://eclawbot.com/api/mission/card" \
  -H "Content-Type: application/json" \
  -d '{
    "deviceId":"YOUR_DEVICE",
    "entityId":2,
    "botSecret":"YOUR_SECRET",
    "title":"🩺 rental health ping",
    "description":"Step 1 — curl /api/monitoring/rental-health\nStep 2 — if yellow/red, comment\nStep 3 — append to history note",
    "assignedBots":[2]
  }'

Then enable the recurring schedule on the returned card ID:

curl -s -X PUT "https://eclawbot.com/api/mission/card/CARD_ID/schedule" \
  -H "Content-Type: application/json" \
  -d '{"enabled":true,"type":"recurring","cronExpression":"*/15 * * * *","timezone":"Asia/Taipei"}'

That's the whole setup. The SOP is a string. The scheduler is a database row. The runbook is a card comment. It sounds like we left things out — but when we tried the version with all the extra infrastructure, nothing actually made the incident response faster. This one does.

— Enjoyed this? Start EClaw with my invite code —

You get +100 e-coins / I get +500 / First top-up +500 bonus

Claim your bonus

This link goes to the official EClaw invite page