operating-ava-cluster

Diagnoses Ava cluster production alerts across disk, memory, connectivity, process, schedule, and delivery failures.

1|Updated Aug 14, 2026
One-click install
npx skills add https://github.com/zhiyuan-zhang0206/Ava --skill operating-ava-cluster-zhiyuan-zhang0206
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: operating-ava-cluster
Source: https://github.com/zhiyuan-zhang0206/Ava/tree/main/.agents/skills/operating-ava-cluster
Command: npx skills add https://github.com/zhiyuan-zhang0206/Ava --skill operating-ava-cluster-zhiyuan-zhang0206

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Operating a production Ava cluster means triaging a constant alert stream and diagnosing recurring failure classes without a clear methodology. This Skill gives the cluster operator a structured playbook for classifying alerts, tracing root causes, and verifying fixes instead of chasing symptoms. ## Core Features & Use Cases - Alert triage workflow: Classify each alert window's events as known/closed, transient, or action-needed, with attribution by machine, service, and incident history. - Diagnosis playbooks: Symptom-to-cause-to-response guides for disk bloat (Postgres checkpoint growth), memory leaks, port conflicts, session-backend mismatches, tripped schedule breakers, and stalled message delivery. - Post-rollout verification: A checklist that catches stale processes, ghost daemons, and duplicate schedule sessions that pid-based status checks miss. - Use Case: After a rollout, an operator sees repeated 'duplicate session' launch failures on a schedule. The playbook identifies the session-backend mismatch as the cause, directs clearing the stale session and restarting via the schedules API, and requires verifying the next fire before closing the incident. ## Quick Start Ask the assistant to triage the last two hours of Ava cluster alerts and diagnose any repeating failure patterns using this playbook.

Frequently Asked Questions about operating-ava-cluster

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I triage Ava cluster production alerts?▼

Pull the alert list for the review window, group by service and pattern, and match groups against known incidents. Classify each as known/closed, transient, or action-needed, then investigate repeating patterns by tracing the root cause rather than the symptom.

How do I fix duplicate session errors on Ava schedules?▼

Duplicate session errors usually mean a session-backend mismatch or a stale pre-rollout session. Clear the stale ava-schedule session, restart via POST /api/schedules/{id}/restart, and verify status returns to running; if it flips back to error within 30 seconds, fix the backend mismatch in code.

Why is my Ava cluster Postgres database growing so fast?▼

LangGraph's PostgresSaver is append-only, so checkpoint threads from terminated agents grow without bound. The checkpoint reaper trims stale and overgrown threads automatically, but physical space still requires VACUUM FULL after large trims.

How do I verify an Ava cluster rollout actually deployed new code?▼

Cluster status alignment is not enough since pid probes only check process existence. Compare service process start times against deploy completion time, check for exactly one mcp daemon per unit, and confirm watchdogs and schedule sessions restarted with the new generation.

Can the operator restart or update Ava cluster services without approval?▼

Emergency restoration such as stopping a crash loop or freeing a stuck port is within operator authority. Rollouts, cluster updates, and irreversible actions like deleting data or killing production processes require explicit user approval scoped to one action.

How do I verify Ava database backups are restorable?▼

Run the automated restore drill script, which decrypts the encrypted artifact, restores it into a throwaway Postgres cluster, and reads checkpoint data through the checkpoint loader. For point-in-time recovery, use the isolated physical PITR drill with a target LSN.