Reference: Cron Config, Webhook Setup, and Slack Integration

Quick-reference for Module 11 — configuring automated triggers and interfaces in Hermes.

1. Hermes Cron Job Configuration

Cron jobs are defined in the agent's config.yaml under the schedules key.

Basic Cron Job

schedules:
  daily_db_health:
    schedule: "0 7 * * *"  # Daily at 07:00 UTC
    task: "Run daily DB health check: review slow queries from last 24 hours, identify top 5 by total_exec_time, flag any queries with execution time > 1000ms average"
    output:
      channel: slack
      target: "#platform-alerts"
      format: markdown
      include_confidence: true
    on_error:
      notify: "#platform-oncall"
      retry: false  # Don't retry on failure — wait for next scheduled run

Cron Job with Conditional Alert

schedules:
  hourly_cost_check:
    schedule: "0 * * * *"  # Every hour
    task: "Check AWS cost-per-hour against yesterday's baseline. Alert only if current hour exceeds baseline by more than 20%."
    output:
      channel: slack
      target: "#finops-alerts"
      format: markdown
      only_if: "anomaly_detected"  # Only post if agent identifies an anomaly
    on_normal:
      log_only: true  # Log to file, don't post to Slack when normal

Cron Job Parameters

Parameter	Values	Description
`schedule`	Cron expression	Standard 5-field cron (minute hour day month weekday)
`task`	String	Task description sent to agent
`output.channel`	`slack`, `email`, `log`, `webhook`	Where output goes
`output.target`	Channel name, email address, URL	Destination within channel
`output.format`	`markdown`, `json`, `plain`	Output format
`output.only_if`	`anomaly_detected`, `alert_triggered`, `always`	Conditional posting
`on_error.notify`	Slack channel or email	Where to send error notification
`on_error.retry`	`true`/`false`	Whether to retry on failure

Common Cron Expressions

Schedule	Expression
Daily at 07:00 UTC	`0 7 * * *`
Every hour	`0 * * * *`
Every 30 minutes	`/30 * * *`
Weekdays at 08:00 UTC	`0 8 * * 1-5`
Monday at 09:00 UTC	`0 9 * * 1`
First of month at midnight	`0 0 1 * *`

2. Webhook Subscription Configuration

Webhooks are configured in Hermes to listen for specific events from external systems.

Basic Webhook

webhooks:
  cloudwatch_alarm:
    path: "/webhooks/cloudwatch"
    method: POST
    validation:
      type: hmac_sha256
      secret_env_var: "CLOUDWATCH_WEBHOOK_SECRET"
    payload_mapping:
      alarm_name: "$.AlarmName"
      metric_name: "$.Trigger.MetricName"
      db_instance: "$.Trigger.Dimensions[?(@.name=='DBInstanceIdentifier')].value"
      state: "$.NewStateValue"
      timestamp: "$.StateChangeTime"
    task_template: |
      ALARM: {alarm_name} is in state {state} as of {timestamp}.
      Investigate {db_instance} for {metric_name} issues.
      Time window: last 30 minutes before {timestamp}.
    route_to_agent: "rds-health-agent"
    output:
      channel: slack
      target: "#db-alerts"

Payload Mapping JSONPath Reference

JSONPath Expression	Purpose
`$.AlarmName`	CloudWatch alarm name
`$.Trigger.MetricName`	Metric that triggered the alarm
`$.Trigger.Dimensions[0].value`	First dimension value (e.g., instance ID)
`$.NewStateValue`	New alarm state (ALARM, OK, INSUFFICIENT_DATA)
`$.StateChangeTime`	ISO 8601 timestamp of state change

PagerDuty Webhook

webhooks:
  pagerduty_incident:
    path: "/webhooks/pagerduty"
    method: POST
    validation:
      type: x_pagerduty_signature
      secret_env_var: "PAGERDUTY_WEBHOOK_SECRET"
    payload_mapping:
      incident_id: "$.messages[0].incident.id"
      title: "$.messages[0].incident.title"
      severity: "$.messages[0].incident.urgency"
      created_at: "$.messages[0].incident.created_at"
    task_template: |
      PagerDuty incident {incident_id}: {title}
      Severity: {severity}, Created: {created_at}
      Run cross-domain investigation across all infrastructure domains.
    route_to_agent: "incident-coordinator"
    output:
      channel: pagerduty
      target: "{incident_id}"  # Append findings to the PagerDuty incident

3. Slack Integration Overview

Slack integration in Hermes has two modes:

Outbound: Agent posts findings to Slack channels (configured in cron and webhook output)
Inbound (slash command): Humans invoke the agent via Slack slash command

Outbound Configuration

integrations:
  slack:
    workspace: "your-workspace"
    auth_env_var: "SLACK_BOT_TOKEN"
    default_channel: "#platform-agents"
    message_format: markdown
    include_timestamp: true
    include_agent_name: true

Inbound (Slash Command) — Overview

Slash command integration requires a Slack App with slash command configuration. This is a demo walkthrough in the lab, not hands-on configuration (requires workspace admin access):

Create a Slack App in your workspace (requires admin)
Add slash command: /hermes → POST to https://your-hermes-host/slack/commands
Configure Hermes with the Slack signing secret
Users can then run: /hermes investigate db-prod-01 slow queries

In the lab: The facilitator demonstrates slash command usage on the training workspace. Participants observe the interaction pattern; actual slash command setup requires workspace admin access that most participants do not have in training environments.

4. Output Routing Reference

Where agent output goes is as important as what the agent produces.

Scenario	Output Routing
Scheduled health report	Slack channel (always post, even if no findings)
Alert-triggered diagnosis	Back to the alert ticket (PagerDuty comment, CloudWatch annotation)
On-call investigation	Direct Slack message to on-call user
Weekly trend summary	Email distribution list
Approval-required action	Slack with approval buttons (Module 13)

Structured Output Format for Routing

Agents posting to external channels should use structured output that renders well in the target medium:

## DB Health: db-prod-01 — 2026-04-01 07:00 UTC

**Status:** ELEVATED (requires monitoring)
**Top Finding:** Slow query average exec time increased 40% vs. 7-day baseline

**Evidence:**
- Top query by exec time: `SELECT * FROM orders WHERE...` (avg 450ms, +180ms vs. baseline)
- Connection pool: 45/100 (45%, within normal range)
- CPU: 32% average (normal)

**Recommendation:** Review query plan for orders table query. Consider adding index on `created_at` column.

**Escalation:** None — monitor trend, report again tomorrow at 07:00 UTC.

*Hermes DB Health Agent | Skill: rds-health-v1.2 | 14:23 elapsed*

This format renders correctly in Slack markdown and provides all information needed to act without clicking through to additional context.

5. Trigger Decision Matrix

Factor	Use Cron	Use Webhook	Use CLI
Human must trigger	No	No	Yes
Needs to respond to events	No	Yes	No
Scheduled at fixed intervals	Yes	No	No
Needs human context in task	No	No	Yes
Best for trending data	Yes	No	No
Best for incident response	No	Yes	Yes (fallback)

6. Phase 8: Real Trigger Types — Comparison

Module 11's existing content (Sections 1-4 above) covers Hermes-native cron and webhook patterns with simulated payloads. Phase 8 adds four REAL trigger sources you wire to live infrastructure:

Trigger Type	Source	When To Use	State Required	Governance Inheritance
Hermes cron (Module 11 Steps 2-4)	Internal scheduler	Most agent work — gateway-shared state, fast iteration, audit trail context	Gateway running	`HERMES_LAB_GOVERNANCE` from gateway env
Hermes webhook test (Module 11 Step 7)	`hermes webhook test` CLI	Lab/development — simulating events without external services	Gateway running	`HERMES_LAB_GOVERNANCE` from gateway env
AlertManager webhook (Phase 8 / TRIG-01)	Real Prometheus + AlertManager on KIND	Event-driven incident response — alerts arrive without polling	KIND cluster + helm release + PrometheusRule applied	`HERMES_LAB_GOVERNANCE` from gateway env (universal inheritance)
K8s CronJob (Phase 8 / TRIG-02)	Kubernetes native CronJob resource	GitOps schedule-in-git, stateless one-shot diagnostics, multi-tenant K8s	KIND cluster + Docker image + Secret	`HERMES_LAB_GOVERNANCE` set on container env spec
GitHub webhook (Phase 8 / TRIG-03)	Real GitHub webhook via smee.io public proxy	PR review automation, push-to-investigate workflows	GitHub repo + PAT + smee.io channel + smee-client running	`HERMES_LAB_GOVERNANCE` from gateway env
Telegram bot (Phase 8 / TRIG-04)	Real Telegram bot via @BotFather	Mobile-first chat ops, on-demand agent invocation from anywhere	Telegram account + bot token + user ID allowlist	`HERMES_LAB_GOVERNANCE` from gateway process env, per-process not per-message

Decision tree

You want a scheduled health check → Hermes cron (default) OR K8s CronJob (if GitOps + K8s primitives matter more than gateway state)
You want event-driven incident response → AlertManager webhook (real metrics-based alerting)
You want code-review automation → GitHub webhook (--deliver github_comment posts back automatically)
You want on-demand chat ops → Telegram bot (or Slack as production reference — see Section 3)
You're prototyping → hermes webhook test with hand-crafted payloads (no external services)

Hermes cron vs K8s CronJob — the honest comparison

Concern	Hermes cron	K8s CronJob
Gateway-shared state (skills, history, audit)	Yes — native	No — stateless container
GitOps schedule in git	No — CLI-managed	Yes — YAML resource
K8s-native observability (job_metrics, pod logs)	No — Hermes session logs only	Yes — Prometheus + Loki/Vector
Multi-tenant resource quotas	No — shared gateway	Yes — namespace + ResourceQuota
Iteration speed	Fast — tweak prompt, re-register	Slow — rebuild image, kubectl apply
Where the agent runs	Gateway process	K8s pod
Image size	n/a (uses host hermes install)	~700-900MB minimal Dockerfile

Real-world stance: most agent work uses Hermes cron because state matters. K8s CronJob shines for fire-and-forget diagnostic jobs deployed alongside other K8s primitives via the same GitOps pipeline.

7. Phase 8 New Environment Variables

Phase 8 adds four new environment variables to the lab export block. The full set as of Phase 8 is:

Env Var	Values	Source	Used For
`HERMES_LAB_MODE`	`mock` \| `live`	Phase 1	Existing
`HERMES_LAB_SCENARIO`	`clean` \| `crashloop2` \| ...	Phase 1 + 6	Existing
`HERMES_LAB_GOVERNANCE`	`L1` \| `L2` \| `L3` \| `L4`	Phase 7	Existing — inherited by triggered agents
`HERMES_LAB_TRACK`	`track-a` \| `track-b` \| `track-c`	Phase 7	Existing
`MOCK_DATA_DIR`	path	Phase 1	Existing
`PATH` (additions)	`infrastructure/wrappers:$PATH`	Phase 1	Existing
`GITHUB_TOKEN`	classic PAT with `repo` scope OR fine-grained PAT with "Pull requests: Read and Write"	Phase 8 (TRIG-03)	GitHub webhook + agent comment posting via `gh pr comment`
`TELEGRAM_BOT_TOKEN`	bot token from @BotFather	Phase 8 (TRIG-04)	Telegram bot connection — activates the Hermes Telegram adapter
`TELEGRAM_ALLOWED_USERS`	comma-separated Telegram user IDs (from @userinfobot)	Phase 8 (TRIG-04)	Restricts which Telegram users the bot will respond to
`SMEE_URL`	`https://smee.io/<channel-id>`	Phase 8 (TRIG-03)	Public webhook proxy URL for forwarding GitHub events to local gateway

How to acquire each

GITHUB_TOKEN: https://github.com/settings/tokens → Generate new token (classic) → check repo scope → copy ghp_... value. Time: ~3 min.
TELEGRAM_BOT_TOKEN: Open Telegram → search @BotFather → /newbot → choose name + username → copy token. Time: ~2 min.
TELEGRAM_ALLOWED_USERS: Open Telegram → search @userinfobot → /start → copy your numeric user ID. Time: ~30 sec.
SMEE_URL: Visit https://smee.io/ → click "Start a new channel" → copy URL. Time: ~30 sec.

Storage: put these in ~/.hermes/.env (gitignored) or export inline before each lab session. NEVER commit real tokens — Telegram and GitHub both have secret-scanning that will flag leaked credentials within minutes.

Governance inheritance: all four trigger types read HERMES_LAB_GOVERNANCE from their execution environment. The K8s CronJob sets it on the container env spec; the AlertManager, GitHub, and Telegram triggers all inherit it from the gateway process env. This means a scheduled or triggered agent running unattended is governed by the same allowlist as an interactive one — there is no special "scheduled agent" governance bypass.

1. Hermes Cron Job Configuration​

Basic Cron Job​

Cron Job with Conditional Alert​

Cron Job Parameters​

Common Cron Expressions​

2. Webhook Subscription Configuration​

Basic Webhook​

Payload Mapping JSONPath Reference​

PagerDuty Webhook​

3. Slack Integration Overview​

Outbound Configuration​

Inbound (Slash Command) — Overview​

4. Output Routing Reference​

Structured Output Format for Routing​

5. Trigger Decision Matrix​

6. Phase 8: Real Trigger Types — Comparison​

Decision tree​

Hermes cron vs K8s CronJob — the honest comparison​

7. Phase 8 New Environment Variables​

How to acquire each​