debug-buttercup

Diagnose Buttercup CRS pod crashes and validate Redis-backed orchestration pipelines.

Updated May 2, 2026
One-click install
npx skills add https://github.com/ayehiaa/my-travel-assistant --skill debug-buttercup-ayehiaa
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: debug-buttercup
Source: https://github.com/ayehiaa/my-travel-assistant/tree/main/.agents/skills/debug-buttercup
Command: npx skills add https://github.com/ayehiaa/my-travel-assistant --skill debug-buttercup-ayehiaa

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve?

This Skill helps you quickly diagnose and resolve Buttercup CRS (Cyber Reasoning System) instability in Kubernetes by guiding you through triage, log analysis, Redis/queue inspection, and common failure cascades.

Core Features & Use Cases

  • CrashLoop and restart-loop triage: identifies pod restart causes (OOMKilled, termination reasons) and correlates failures via events and logs.
  • Redis-centric debugging: checks Redis health (AOF persistence, disk mounting, memory/disk behavior) since Redis downtime often triggers system-wide cascades.
  • Pipeline/queue validation: inspects Redis stream lengths and consumer-group lag to determine whether tasks are stuck or not being processed.
  • Operational scope: focused on the crs namespace and Buttercup services across infra, orchestration, fuzzing, analysis, and UI/API surfaces.

Quick Start

Run the automated triage snapshot with full verbosity to capture pod status, events, resource usage, Redis health, and queue depths in one pass.

Frequently Asked Questions about debug-buttercup

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

FAQPage Schema
How do I triage a Kubernetes CrashLoopBackOff in the crs namespace?

Triage a CrashLoopBackOff by running the automated diagnose script with full verbosity to capture pod status, events, and last-state termination reasons like OOMKilled. It correlates restart cascades across Buttercup services.

How do I check Redis stream queue depth and consumer group lag?

Check Redis stream queue depth and consumer group lag by executing Redis CLI INFO commands and inspecting stream lengths. This validates whether orchestration tasks are stuck or not being processed within the Buttercup pipeline.

Why are my Buttercup CRS pods restarting continuously?

Buttercup CRS pods restart continuously due to OOMKilled, resource pressure, or Redis unresponsiveness triggering system-wide cascades. Use kubectl to interpret pod last-state and events, and verify Redis AOF persistence and disk mounting.

Can I inspect DinD connectivity issues within the crs namespace?

Yes, you can inspect DinD connectivity issues by running the diagnose script to collect recent logs and pod events. The Skill targets DinD connectivity problems alongside probe failures and disk pressure within the crs namespace.

What is the best way to debug a stuck Buttercup scheduler?

The best way to debug a stuck Buttercup scheduler is to inspect Redis stream lengths and consumer-group lag to determine if tasks are queued but unprocessed. Run Redis health checks and collect logs via the diagnose script.