GoDaddy — Observability Platform

Overview

I spent Summer 2026 as a Software Engineering Intern on GoDaddy's Observability Platform team — the team that owns the internal Elasticsearch/Kibana-backed stack other engineering teams use to diagnose production issues. My work centered on the APIs and tooling layer sitting on top of that stack: production REST endpoints, an MCP integration, and the documentation and tests that let other engineers actually rely on what I shipped.

Problem

Observability platforms only prove their value when someone can find the right answer in minutes instead of hours. That depends as much on the tooling and API layer around the data store as on the data store itself — a team with `logs somewhere in Elasticsearch` has an incident tool; a team with well-documented, well-tested APIs on top of it has a platform other people can actually build on.

The exact starting gap on the team is internal — described here in general terms rather than specifics that would need sign-off to publish.

Architecture

At a high level, application services emit structured logs and metrics, which flow into an Elasticsearch cluster and get visualized in Kibana. My work sat in the layer between that stack and the engineers who need to query or automate against it — a FastAPI service layer exposing clean REST endpoints, plus an MCP integration so the same data is reachable by AI tooling, not just dashboards. Hover each stage below.

Tech Stack

MCP (Model Context Protocol) is the most distinctive piece of this stack — it's a genuinely current, AI-tooling-relevant addition most peer internship experiences won't have touched yet.

Implementation

• Designed and shipped production REST API endpoints, with input validation and consistent response schemas, consumed by other engineering teams.
• Built developer tooling that reduced friction in how engineers interact with the observability stack.
• Implemented an MCP integration, extending the platform's data to tool-based/agentic access patterns.
• Wrote architecture documentation for the systems touched, intended to shorten onboarding for future engineers.
• Covered new endpoints with unit and integration tests as part of the team's standard release process.

Challenges

The general challenge of working inside a platform other teams depend on: any API contract change has a blast radius a personal project never does, which means slower, more deliberate iteration than a from-scratch build — a real adjustment coming from self-directed projects.

Replace this section with one specific, concrete debugging or design story before this page goes live — it's the most convincing part of any case study, and currently this is a general placeholder rather than a real incident.

Tradeoffs

A recurring tradeoff in this kind of work is exposing a thin, opinionated API over a powerful underlying system (Elasticsearch's native query language) rather than the raw interface — trading some flexibility for a much safer, simpler contract that other teams can call without needing to understand the store underneath it.

Engineering Decisions

Two decisions mattered most to how this work turned out: documenting architecture as I built rather than after (so the docs reflect real decisions, not idealized ones), and treating tests as part of the definition of "done" for an endpoint rather than a follow-up task.

Lessons Learned

Working inside a platform other teams depend on changes how you think about backward compatibility and documentation — a broken internal API has a blast radius a personal project never does, and "it works on my machine" stops being a meaningful bar.

Future Improvements

Given more time on the team, the natural next steps would be expanding MCP tool coverage further and instrumenting the API layer itself with the same observability practices it exposes to other teams — eating your own dog food.

Interview Story

Timeline

Illustrative breakdown of a 12-week internship — replace with the real schedule.