Business Heartbeat Monitor

HEARTBEAT.md framework for continuous business monitoring — sites, services, inbox, payments, processes, and revenue.

Security Scan

The SKILL.md asks an agent to perform broad monitoring and active remediation (restart services, read inboxes, pull payments/revenue, send alerts) but the package declares no credentials, no install, and gives no safe limits — the requirements and instructions are not internally consistent.

Purpose & Capability

The skill claims to be a business heartbeat monitor (sites, services, inbox, payments, processes, revenue) but the skill metadata declares no required environment variables, credentials, or binaries. Realistically, implementing the described checks (email inbox scanning, payment retries, DB/queue checks, service restarts, posting to Slack/Telegram/Discord, pulling revenue data) requires access credentials and integration tooling. The absence of any declared credential or integration requirement is a significant mismatch.

Instruction Scope

SKILL.md instructs the agent to scan inboxes, pull complete revenue data, retry payments, restart/kil processes and redeploy services, and auto-send replies/alerts. These are sensitive, state-changing operations and the instructions are permissive (e.g., 'Attempt restart', 'restart automatically', 'send if within Tier 1 autonomy') without specifying safe boundaries, authorization checks, or where credentials come from. The guidance is broad and could cause destructive actions if executed with high privileges.

Install Mechanism

This is an instruction-only skill with no install spec and no code files. That lowers the immediate supply-chain risk because nothing is downloaded or written by the skill itself.

Credentials

The runtime instructions imply needing credentials and API access for multiple unrelated systems (email provider, payment gateway, DB, deployment/orchestration, Slack/Telegram/Discord). Yet requires.env and primary credential fields are empty. The skill both requires broad, sensitive access in practice and declares none — an incoherence that could hide credential-exfiltration vectors or simply be an under-specified, dangerous design.

Persistence & Privilege

always is false (good), but disable-model-invocation is also false so the agent may invoke autonomously. Combined with the skill's instructions to perform writes and restarts across many systems, this raises risk: an autonomous agent with existing credentials could take destructive actions. The skill doesn't request persistent presence but it does assume operational privileges that should be constrained and audited.

What to consider before installing

Do not install this skill as-is. The SKILL.md expects access to email, payment systems, databases, deployment tooling, and alert channels but the package declares no credentials or integration points — that mismatch is a red flag. If you want this functionality, require the following before installing: (1) a vetted source/homepage and owner verification; (2) explicit, minimal-scoped environment variables and documented integrations (read-only DB creds where possible, separate service accounts for restarts, payment-webhook-only access instead of full payment provider admin passwords); (3) strict autonomy rules: require human approval for destructive actions (restarts, kills, payment retries); (4) run first in staging with audit logging and limited privileges; (5) add clear rate-limiting and safe-guards in the instructions (what to do on repeated failures, escape hatches). Treat any deployment or payment credentials as high-sensitivity secrets and prefer ephemeral tokens and least-privilege roles. If the owner cannot explain where credentials come from and how actions are authorized/audited, do not use this skill.

Your agent runs heartbeats on a schedule. Each cycle is an opportunity to check on everything that matters and fix what's broken — before anyone notices.

This skill provides a complete HEARTBEAT.md framework for business operations monitoring.

Core HEARTBEAT.md Template

## Production Site Health (every heartbeat)
1. Check all production URLs for 200 status with expected content:
   - yoursite.com — expect 200 + contains "Your Brand"
   - app.yoursite.com — expect 200
   - api.yoursite.com/health — expect 200 + {"status":"ok"}
2. If any fail:
   - Attempt restart (via deployment redeploy, service restart, etc.)
   - If auto-recovery works: log to daily notes, move on
   - If auto-recovery fails: alert immediately on primary channel
3. Log all results to daily notes

## Service & Infrastructure Health (every heartbeat)
1. Check critical background services are running
   - Database connections responding
   - Queue workers processing
   - Cron jobs firing on schedule
2. If a service is down:
   - Attempt restart
   - If restart fails: alert with error details
3. If a process has been stalled for 2+ consecutive heartbeats:
   - Kill and restart automatically
   - Log the stall duration and any error output

## Support SLA Check (every heartbeat)
1. Scan inbox for unanswered customer messages
2. Flag any message older than your SLA threshold (e.g., 4 hours)
3. For routine questions (order status, how-to, account access):
   - Draft a response
   - Send if within Tier 1 autonomy, otherwise flag for review
4. For complex issues:
   - Summarize the problem
   - Flag for human review with recommended action

## Payment & Revenue Check (every heartbeat, summarize nightly)
1. Check for failed payments or declined charges
2. Flag any for retry or customer follow-up
3. Track daily revenue running total
4. Note any anomalies (unusual spikes, drops, large transactions)

## Background Process Health (every heartbeat)
1. Check for any listed active processes (tmux sessions, workers, agents)
2. For each: verify it's still running
3. If dead: restart automatically, log what happened
4. If stalled (same output for 2+ checks): kill and restart
5. If completed successfully: report completion, clean up

Nightly Deep Dive Template

Run once per day (e.g., 3 AM):

## Nightly Deep Dive (~3 AM)

### Revenue Review
1. Pull yesterday's complete revenue data
2. Break down by product/service
3. Compare to trailing 7-day and 30-day averages
4. Note what sold, what didn't, any patterns

### Day Review
1. What got done from today's plan?
2. What didn't get done and why?
3. What blocked progress?

### Tomorrow's Plan
1. Propose 3-5 concrete priorities ranked by expected impact
2. Each item should connect to a clear business goal
3. Include execution tasks and growth experiments
4. Write to tomorrow's daily notes file

### Health Summary
1. Uptime: percentage across all monitored services
2. Incidents: any outages or degradations, with resolution
3. Support: messages handled, average response time
4. Revenue: daily total, trend direction

Integration with Autonomy Ladder

The monitoring system works best when paired with clear autonomy tiers:

Monitor Finding	Autonomy Tier	Action
Site returning 500	Tier 1	Fix + log
Background process crashed	Tier 1	Restart + log
Support email >4 hours	Tier 1/2	Draft response, send if routine
Payment failed	Tier 2	Retry + report
Revenue anomaly	Tier 2	Investigate + report
Service architecture issue	Tier 3	Diagnose + propose fix
Customer escalation	Tier 3	Summarize + flag

Daily Notes Format

Each heartbeat should append to the day's notes:

## Heartbeat — 3:15 PM

### Health
- ✅ All sites returning 200
- ✅ All services healthy
- ⚠️ Worker queue backed up (47 pending, normally <10)
  - Cause: spike in API requests from new integration
  - Action: scaled workers from 2 → 4, queue clearing

### Support
- 2 new messages since last check
- Replied to order status inquiry (Tier 1, auto-sent)
- Flagged billing dispute for review (Tier 3)

### Revenue
- Running total: $342 (vs $289 yesterday at this time)

Setup Checklist

1. Copy the HEARTBEAT.md template above
2. Replace example URLs with your actual production endpoints
3. Set your SLA threshold (4 hours is a good default)
4. Configure alerting channel (Telegram, Discord, Slack, etc.)
5. Define which background processes to monitor
6. Set your nightly deep dive time (2-4 AM recommended)
7. Pair with the Autonomy Ladder for escalation rules

Tips

• Start with site health only. Get that working reliably before adding inbox triage and revenue tracking. Each layer of monitoring adds complexity.
• Don't alert on everything. The goal is signal, not noise. If your agent sends 15 "all clear" messages a day, you'll start ignoring them — and miss the one that matters.
• Log everything, alert selectively. Every heartbeat result goes in daily notes. Only failures and anomalies get sent to your channel.
• Review weekly. Check the daily notes for patterns. If the same service keeps restarting, that's not a monitoring success — it's an infrastructure problem to fix.