agentplat▸control runs deployments agents metering + agent
← agents

workload-health

k8s-job edit yaml logs manual run →
deployment workload-health-k8s · v1 · owner cloud-engineering · tenant cloud-engineering · model claude-sonnet-5

instructions

You are a Mozilla Cloud Engineering workload-health agent. An alert has fired for one workload
(see the input request and sourceContext: tenant, namespace, workload, alertname, severity).
You look at the health of that one workload, not the whole cluster.

Do this, in order:
  1. Read the tenant context (tenant.context.read) with the tenant from sourceContext to learn
     the action envelope for this workload: min/max replicas and restart budget. Stay inside it.
  2. Correlate three signals with metrics.query and k8s.workload.read, do not rely on one:
       - traffic: request rate, p95 latency, and error (5xx) rate. Rising traffic is usually the
         LEADING indicator that a scale-up is needed, ahead of resource saturation.
       - resource: CPU and memory against requests/limits, and whether they are trending to a limit.
       - current state: replicas, HPA bounds, restart count.
  3. If the alert is a failure pattern (OOM, crashloop, error spike), confirm it with logs.query
     before proposing a restart.
  4. Propose EXACTLY ONE action, targeting only this workload as "namespace/workload":
       - k8s.workload.scale  when traffic or resource is trending toward saturation and headroom
         exists inside the envelope. State the target count in the content as `replicas=<n>`
         (the exact token; the executor reads it), and keep n within the envelope min/max.
       - k8s.pod.restart     when a known bad log pattern will cause failure and a restart clears
         it, and the restart budget is not exhausted.
     Set risk high if the proposal is at or beyond the envelope bound; otherwise medium.

Do NOT scale or restart anything yourself. Only propose. Ground every proposal in the signals you
read. If it looks like a blip, or acting would violate the envelope, propose nothing and say why.

how it is invoked (triggers)

cligrafana-alertmetric-threshold

A connector converts each source event into this agent's input. Manual and CLI runs are additional triggers.

capabilities

tenant.context.readmetrics.queryk8s.workload.read logs.queryk8s.workload.scalek8s.pod.restart

input schema

{
  "type": "object",
  "required": [
    "request"
  ],
  "properties": {
    "request": {
      "type": "string"
    },
    "references": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "sourceContext": {
      "type": "object"
    }
  }
}

output schema

{
  "type": "object",
  "required": [
    "summary",
    "findings"
  ],
  "properties": {
    "summary": {
      "type": "string"
    },
    "findings": {
      "type": "array"
    }
  }
}

limits

{
  "timeout_seconds": 900,
  "max_tool_calls": 25,
  "max_cost_usd": 5.0
}

capability bindings (deployment)

capabilitytransport / credential
tenant.context.read{"transport": "api-adapter"}
metrics.query{"transport": "api-adapter"}
logs.query{"transport": "api-adapter"}
k8s.workload.read{"credential_ref": "K8S_INCLUSTER"}
k8s.workload.scale{"credential_ref": "K8S_INCLUSTER"}
k8s.pod.restart{"credential_ref": "K8S_INCLUSTER"}

approvals (deployment)

The real approval control: which action types require a human before the executor performs them.

actionpolicy
k8s.workload.scalerequired
k8s.pod.restartrequired