health

name	health
description	Announce agent status to Dailybot and receive pending messages. Use at session start, periodically during long sessions, or at session end.
allowed-tools	Bash, Read

Dailybot Health Check

Announce the agent's status (online, working, offline, degraded) to Dailybot so the team knows whether the agent is alive and what it's doing. Health check responses also deliver pending messages from the team.

---

When to Use

• At the start of a work session — announce "online and ready"
• Periodically during long sessions — every 15–30 minutes, to stay visible and pick up new messages
• At the end of a work session — announce completion or going offline
• When the agent enters a degraded state — persistent errors, blocked on something
• When the user asks to "go online", "announce status", or "check in with the team"

---

Step 1 — Verify Setup

Read and follow the authentication steps in ${CLAUDE_PLUGIN_ROOT}/shared/auth.md. That file covers CLI installation, login, API key setup, and agent profile configuration.

If auth fails or the user declines, skip and continue with your primary task.

---

Step 2 — Detect Agent Name

Run the bundled context detection script:

bash "${CLAUDE_PLUGIN_ROOT}/scripts/detect-context.sh"

Capture the agent_name value from the JSON output.

Fallback — if the script fails, use the default agent name "claude-code".

---

Step 3 — Choose Execution Path

command -v dailybot

• CLI found → Step 4A
• CLI not found → Step 4B (see ${CLAUDE_PLUGIN_ROOT}/shared/http-fallback.md for base curl patterns)

---

Step 4A — Health Check via CLI

Timeout: Allow at least 30 seconds for CLI commands to complete. Do not use a shorter timeout.

Announce healthy status

dailybot agent health --ok --message "Working on <task>" --name "<agent_name>"

Announce degraded/failing status

dailybot agent health --fail --message "DB unreachable — retrying" --name "<agent_name>"

Check current health status

dailybot agent health --status --name "<agent_name>"

---

Step 4B — Health Check via HTTP API

Send health check

curl -s -X POST https://api.dailybot.com/v1/agent-health/ \
  -H "X-API-KEY: $DAILYBOT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "agent_name": "<agent_name>",
    "ok": true,
    "message": "Working on <task>"
  }'

Request fields

Field	Required	Description
agent_name	Yes	Your consistent agent identifier
ok	Yes	true for healthy, false for degraded/failing
message	No	Brief description of current state

Response

{
  "agent_name": "<agent_name>",
  "status": "healthy",
  "last_check_at": "2026-02-11T10:00:00Z",
  "pending_messages": [
    {
      "id": "msg-uuid",
      "content": "Please prioritize the auth bug fix before the feature work",
      "message_type": "text",
      "sender_type": "human",
      "sender_name": "Alice",
      "metadata": {},
      "created_at": "2026-02-11T09:30:00Z"
    }
  ]
}

Retrieve last health status

curl -s -X GET "https://api.dailybot.com/v1/agent-health/?agent_name=<agent_name>" \
  -H "X-API-KEY: $DAILYBOT_API_KEY"

---

Step 5 — Handle Pending Messages

Health check responses include pending_messages. These are instructions from the team — act on them.

When you receive messages:

1. Read all pending messages
2. Prioritize accordingly — if a message changes priorities, adjust your plan
3. Incorporate context into your current work
4. Acknowledge receipt in your next progress report (via the /dailybot:report skill)

If messages are found, summarize them for the user:

"Health check sent. You have 1 message from your team:

Alice (2 hours ago): Please prioritize the auth bug fix before the feature work

Want me to adjust priorities?"

If no messages:

"Health check sent — status: online. No pending messages."

---

Periodic Check-in Pattern

For long-running sessions, send health checks every 15–30 minutes. This keeps the agent visible to the team and ensures messages are picked up promptly.

Session start → health check (ok, "Starting work session")
   ... 15-30 min ...
Working       → health check (ok, "Working on auth refactor — 3 of 5 tasks complete")
   ... 15-30 min ...
Working       → health check (ok, "Finishing test suite for auth module")
   ... task complete ...
Session end   → health check (ok, "Session complete — auth refactor shipped")

If the agent encounters persistent errors:

Error state   → health check (fail, "Docker build failing — missing libpq-dev dependency")

---

Non-Blocking Rule

Health checks must never block your primary work. If the CLI is missing, auth fails, the network is down, or the command errors:

1. Warn the user briefly
2. Continue with the primary task
3. Do not retry automatically
4. Do not enter a diagnostic loop