Jeranix

When an application or server incident happens, developers and IT teams often have to reason through noisy information quickly. Logs, stack traces, monitoring events, service names, timestamps, deployment changes, and user reports may all arrive at once while the team is trying to restore service.

The problem is not only technical difficulty; it is cognitive load. Under pressure, teams need to group related signals, understand timing, identify likely affected services, decide severity, and document what happened without losing important details.

Jeranix was built around that incident-analysis workflow. The product uses AI assistance to organize evidence and suggest possible explanations, but it is framed as a review tool for developers and incident responders, not as an automatic root-cause authority.

Logs and stack traces can be fragmented across services, files, tools, and time windows. A single error message may be repeated hundreds of times, while the first meaningful signal may be buried near a deploy event, dependency failure, configuration change, or upstream timeout.

Without structure, teams spend time manually grouping events, comparing timestamps, deciding what is related, and writing incident notes after the fact. Important context can be lost once the immediate pressure is over.

The product problem was to turn raw failure signals into a clearer incident timeline. Jeranix needed to parse logs, extract services and timestamps, group related events, classify severity, suggest possible root-cause hypotheses, and support post-incident documentation.

Jeranix lets users upload logs, stack traces, error reports, or monitoring snippets. The system extracts structured signals such as timestamps, services, error codes, stack frames, severity hints, repeated patterns, and related events.

Those signals are grouped into an incident timeline so users can review what happened in order. The AI layer can suggest possible root-cause hypotheses and troubleshooting steps, but the wording stays review-oriented because incident diagnosis still requires developer judgment.

The system can also generate a post-incident report draft. That draft helps teams capture symptoms, timeline, suspected cause, impact, mitigation steps, and follow-up actions while the evidence is still organized.

I built Jeranix as a solo full-stack MVP, owning the product framing, log ingestion workflow, parsing logic, incident timeline structure, AI analysis flow, troubleshooting output, and report-generation interface.

The implementation scope focused on log upload, service and timestamp extraction, error grouping, severity classification, timeline building, possible root-cause suggestions, debugging steps, and postmortem-style report generation.

The key product decision was to keep the system evidence-first. Jeranix should help responders reason faster by organizing signals, but it should not pretend to know the final cause without human review.

The workflow begins when a user uploads logs, stack traces, monitoring output, or an incident report. The system parses the input for timestamps, services, environments, error codes, repeated messages, stack frames, and other operational signals.

Related signals are grouped into a timeline so the user can see how the incident unfolded. The system can highlight repeated failures, severity indicators, affected services, and suspicious timing patterns that may help narrow the investigation.

The final output includes possible root-cause hypotheses, troubleshooting steps, and a draft incident report. The user can review, edit, and use that output as a starting point for debugging or post-incident documentation.

Jeranix is structured around a Next.js and React frontend, Tailwind CSS interface, FastAPI backend, PostgreSQL records, Python log parsing, OpenAI API usage, incident timelines, severity classification, and report generation.

The data model separates uploaded log bundles, parsed events, services, timestamps, error groups, severity labels, incident timelines, analysis notes, troubleshooting steps, and report drafts. This keeps raw evidence connected to the generated analysis.

The parsing layer extracts structure from messy input before AI analysis is applied. That matters because incident tools are more useful when they organize evidence first, then generate explanations based on that evidence.

A production version would need integrations with monitoring tools, issue trackers, deployments, alerting systems, and source repositories. It would also need stronger grouping accuracy, permissions, audit trails, and evaluation against realistic incident bundles.

Jeranix is a working MVP focused on incident analysis and operational documentation. It demonstrates log ingestion, pattern extraction, event grouping, severity classification, timeline building, possible root-cause suggestions, troubleshooting steps, and post-incident reports.

The current version is strongest as a developer-tool workflow proof of concept. It should be described as an assistant for organizing evidence and suggesting hypotheses, not as a guaranteed root-cause engine.

The next step would be testing against realistic log bundles, improving event grouping, adding monitoring and issue-tracker integrations, and making report drafts easier to edit into team-ready postmortems.

The main outcome of Jeranix is an incident workspace that turns noisy logs into structured signals, timelines, hypotheses, and documentation. It helps responders move from raw failure data to a clearer investigation path.

From an engineering perspective, the project strengthened my work with log parsing, backend processing, AI-assisted analysis, operational data modeling, timeline interfaces, and report-generation workflows.

From a product perspective, Jeranix shows that developer tools should reduce pressure during incidents. The product is useful when it helps teams reason faster, preserve evidence, and document what happened more clearly.

Jeranix made me think about developer tools as pressure reducers. During incidents, teams need structure quickly, and a good tool should make evidence easier to scan rather than adding another layer of noise.

The project also reinforced the importance of careful language around root cause. A system can suggest hypotheses, but engineers still need to verify the cause against logs, deployments, metrics, and domain context.

The broader lesson is that AI can be useful in DevOps when it organizes evidence and accelerates documentation. Jeranix gave that idea a concrete workflow through parsing, grouping, timelines, hypotheses, and report drafts.