Giulio
Connect a Vercel project, describe a problem, and receive a Gemini-powered incident report grounded in deployment and runtime logs.
Giulio was our attempt to connect an application, gather its real operational signals, explain what went wrong, and turn that diagnosis into an actionable incident report and pull request.
The situation.
The initial idea was broad. Giulio would pull signals from Vercel, AWS CloudWatch, PostHog, and other log providers, identify the likely problem, explain the evidence, and create a pull request that helped move the incident towards a fix.
For the hackathon, we narrowed that vision to Vercel applications. A user could connect a project, describe a problem, optionally include a user ID, and receive a grounded diagnosis based on recent deployments, build logs, and runtime errors rather than a generic answer from an AI chat interface.
What I did.
I worked on the product concept and prototype engineering as part of the hackathon team. We built Giulio as a Turborepo with a Next.js dashboard, Supabase authentication and Postgres storage, Drizzle ORM, Gemini through the Vercel AI SDK, a Hono bot service, and shared integration and type packages.
The Vercel flow stored provider tokens encrypted at rest, fetched project and deployment data, collected build and drained runtime logs, reduced repeated events into useful fingerprints, and sent bounded context to Gemini. The resulting incident saved a summary, severity, root-cause hypothesis, evidence, and next steps for later review.
The repository also contains a working GitHub pull-request flow. It creates a branch, commits an incident investigation file, opens a pull request containing logs, stack traces, analysis, and evidence, then stores the resulting URL. It did not yet generate and verify an automatic code fix, which remained a later step.
How the work unfolded.
Connected a real Vercel project
Built setup states for registering an application, linking one Vercel project, and keeping its access token encrypted and server-side.
Reduced logs before analysis
Prioritised recent production deployments, grouped repeated messages into fingerprints, ranked signals by severity, frequency, and recency, and surfaced exact user-ID matches when provided.
Returned a grounded incident report
Used Gemini to structure the likely issue, root cause, supporting evidence, confidence, scope, and recommended debugging steps, then persisted the result as an incident.
Carried the diagnosis into GitHub
Implemented branch, commit, and pull-request creation so incident context could move into the repository instead of ending as an isolated chat response.
What happened.
During the hackathon, we realised the problem was much harder than we had expected. Reliable incident analysis depends on obtaining complete, timely data from several systems, normalising incompatible signals, managing credentials and permissions, and knowing when the evidence is too weak for a confident answer.
The most immediate blocker was Vercel Log Drains. We had access to the Pro trial, but Log Drains were excluded from that trial and required a paid Pro or Enterprise plan. That meant the live runtime-log path at the centre of the demo could not be exercised as freely as we had planned, even though the repository contains the drain ingestion and analysis plumbing.
The experience gave me much more respect for companies such as incident.io that focus on software reliability and incident response. What looked like a straightforward pipeline from logs to diagnosis was actually a deep product and infrastructure problem involving integrations, evidence quality, human coordination, security, and the consequences of getting the answer wrong.
What I learned.
Data access is part of the product
A good analysis model cannot compensate for logs that are unavailable because of plan limits, short retention, missing permissions, or an integration that was never configured.
Logs need reduction, not just collection
Sending a large stream directly to a model wastes context and makes repeated noise look important. Deduplication, ranking, time windows, and representative examples shape the quality of the diagnosis.
Evidence has to remain visible
A root-cause hypothesis becomes useful when an engineer can inspect the deployments, fingerprints, log examples, and confidence behind it rather than trusting a polished paragraph.
A pull request is not automatically a fix
Moving incident context into GitHub is valuable, but generating a safe code change requires repository understanding, testing, review, and stronger confidence than producing an investigation document.
Incident response is a full discipline
The hackathon made the depth of companies such as incident.io much clearer. Diagnosis is only one part of a system that also needs response, coordination, history, permissions, and prevention.
Related links.
Repositories, demos, event pages, posts, and other places connected to this project.
- Giulio repository and READMEPrimary source for the implemented architecture, Vercel analysis flow, technology stack, project status, and licence.
- Vercel incident chat planDocuments the scoped Vercel workflow, encrypted credentials, bounded log collection, Gemini report, evidence panel, and incident persistence.
- Giulio pull-request featureDocuments the implemented branch, investigation commit, pull-request, database tracking, and failure-handling flow.
- Giulio Slack and provider planRecords the wider GitHub, Vercel, and PostHog workflow planned around the prototype.
- Vercel Drains documentationOfficial source confirming that Drains require Pro or Enterprise and are unavailable on Hobby and Pro Trial plans.
- incident.ioOfficial source for the software-reliability and incident-response platform referenced in the reflection.