Debugging Omnistrate Deployments

Diagnose Omnistrate deployment failures with a two-phase JSON workflow.

Updated Oct 15, 2025

Search Tags:#workflow #debugging #kubectl #root-cause #deployments #Omnistrate #remote-tunneling

Ready to run

npx skills add https://github.com/omnistrate-oss/agent-instructions --skill debugging-omnistrate-deployments-omnistrate-oss

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: Debugging Omnistrate Deployments
Source: https://github.com/omnistrate-oss/agent-instructions/tree/main/skills/omnistrate-sre
Command: npx skills add https://github.com/omnistrate-oss/agent-instructions --skill debugging-omnistrate-deployments-omnistrate-oss

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps engineers systematically debug failed Omnistrate deployments by guiding a progressive workflow that quickly identifies the root cause while minimizing token usage.

Core Features & Use Cases

Progressive two-phase workflow: Phase 1 provides a concise workflow-status summary; Phase 2 retrieves detailed events for failing resources.
Remote debugging with Omnistrate: Use remote kubeconfig to inspect pods, events, and logs without direct cluster access, including Helm verification when needed.
Structured failure analysis: Build actionable root-cause analyses, including timeline visuals and recommended resolutions for infrastructure, application, and configuration layers.
Use Case: Troubleshoot an instance stuck in DEPLOYING by identifying misconfigured probes or missing dependencies and validating fixes end-to-end.

Quick Start

Start by obtaining the deployment status: omctl instance describe <instance-id> --deployment-status --output json
Identify workflows for the failing deployment: omctl workflow list --service-id <service-id> --environment-id <environment-id> --instance-id <instance-id> --output json
Drill into details for failed steps (Phase 2): omctl workflow events <workflow-id> --service-id <service-id> --environment-id <environment-id> --detail --resource-key <resource> --step-types <type> --output json
If probes or pod issues are observed, connect via remote tunneling: omctl deployment-cell update-kubeconfig <cell-id> --kubeconfig /tmp/kubeconfig kubectl get pods -n <instance-id> --kubeconfig /tmp/kubeconfig kubectl logs <pod-name> -c service -n <instance-id> --kubeconfig /tmp/kubeconfig --tail=50
For Helm-type resources, verify deployment state: omctl deployment-cell update-kubeconfig <cell-id> --kubeconfig /tmp/kubeconfig --role cluster-admin helm list -n <instance-id> --kubeconfig /tmp/kubeconfig helm status <release-name> -n <instance-id> --kubeconfig /tmp/kubeconfig

Frequently Asked Questions about Debugging Omnistrate Deployments

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

FAQPage Schema

How do I debug an Omnistrate deployment stuck in FAILED or DEPLOYING status?▼

Debug a failed Omnistrate deployment by running a two-phase workflow: first summarize workflow statuses with omctl, then retrieve detailed events for failing resources to isolate the root cause.

How do I access pods and logs in an Omnistrate deployment without direct cluster access?▼

Access pods and logs without direct cluster access by using remote kubeconfig via omctl deployment-cell update-kubeconfig, enabling you to run kubectl commands like get pods and logs through remote tunneling.

What is the best way to identify root causes for probe failures in Kubernetes deployments?▼

Identify root causes for probe failures by drilling into detailed workflow events with omctl, then connect via remote kubeconfig to inspect pod logs and validate misconfigured probes or missing dependencies.

How do I verify Helm release states for failed Omnistrate instance deployments?▼

Verify Helm release states by updating your remote kubeconfig with cluster-admin role, then running helm list and helm status commands against the specific instance namespace to check deployment state.

Does the Omnistrate debugging workflow minimize token usage during root-cause analysis?▼

The debugging workflow minimizes token usage by using a progressive two-phase approach and requesting JSON-based outputs for workflow summaries and detailed events instead of raw text logs.

Can I troubleshoot infrastructure, application, and configuration layer failures with this workflow?▼

Troubleshoot infrastructure, application, and configuration layer failures by building a structured root-cause analysis from workflow events, pod logs, and Helm status outputs into actionable resolutions.