PipelineMedic — Diagnose CI/CD Failure

Inspiration

I work in DevOps and have three years of experience as a full-stack software engineer. Most of my CI/CD experience comes from running Jenkins and GitLab CI in on-premises environments. When a pipeline fails, the investigation often involves moving between job logs, configuration files, runner settings, and different provider interfaces. I wanted to bring that context into one workspace and help engineers understand a failure before deciding what to change. That idea became PipelineMedic.

What it does

PipelineMedic is a centralized CI/CD configuration and failure investigation workspace for developers and DevOps engineers. The dashboard shows normalized pipeline health and a failure inbox. From a failed run, users can inspect its logs, configuration, and runtime context, then request a diagnosis. Findings include evidence citations that link to specific log lines, suggested next steps, and verification checks. The application also includes:

• A pipeline configuration catalog with local revision history.
• A log sandbox for pasted or uploaded failure logs.
• Deterministic local rules and optional cloud or self-hosted AI providers.
• Four read-only MCP tools for accessing runs and diagnostic advice through an assistant. PipelineMedic does not execute repairs or change infrastructure. Engineers remain responsible for reviewing evidence and approving changes. ## How I built it I built PipelineMedic with JavaScript, Next.js, React, and Node.js. SQLite stores pipeline records, configuration revisions, and normalized runs. Docker and Compose configurations are included for containerized operation. I used Codex as a coding collaborator and the Devpost Learn Skill Pack to organize the project. I supplied the product direction, stack preferences, and visual style, then reviewed the application and requested improvements. The web application and MCP server share the same diagnosis services. Inputs are validated and processed through best-effort secret redaction. Diagnostic results are checked for structure and valid evidence references before being displayed. The interface uses a dark, simple design with readable logs and clear distinctions between evidence, advice, and uncertainty. ## Challenges I ran into The largest product challenge was keeping the idea focused. Centralized CI/CD management can quickly become a large orchestration platform. I narrowed the proof of concept around one useful journey: moving from a failed run to an evidence-backed next step. Another challenge was making diagnostic advice trustworthy. A plausible explanation is not enough, so findings need citations and verification steps. When evidence is insufficient, the application requests more context instead of presenting an unsupported root cause. Handling sensitive logs also required care. Redaction helps reduce accidental disclosure, but it is not perfect, so users need to review their input before sending it to a model. Finally, I needed to distinguish local rules from AI analysis clearly. The demo uses synthetic data and deterministic rules; it does not claim to demonstrate live AI performance. ## Accomplishments I'm proud of I am proud of completing a connected workflow across the dashboard, failed-run investigation, configuration catalog, and log sandbox. The evidence navigation is especially useful: clicking a citation highlights the exact log line behind a finding, making the advice easier to inspect. ## What I learned Before this project, I mainly used AI coding agents for debugging, updates, and refactoring. PipelineMedic gave me experience using an agent to develop a broader product idea while making the important decisions myself. The project reinforced the value of defining a clear scope, making requirements testable, and checking generated behavior against evidence. It also helped me explore CI/CD failure categories beyond my on-premises experience, including cloud identity problems and failures where the available logs cannot establish a root cause. ## What's next for PipelineMedic The next step is to connect real CI providers through authenticated adapters and webhooks, starting with Jenkins and GitLab and expanding to cloud services. I also want to evaluate cloud and self-hosted AI providers with realistic, sanitized failures and measure the quality of their evidence and recommendations. Longer-term improvements include team access controls, audit history, notifications, and PostgreSQL-backed deployment. The guiding principle will remain the same: make failures easier to understand while keeping every repair under human control.

Built With

• docker
• javascript
• model-context-protocol
• next.js
• node.js
• react
• sqlite
• zod