Scribe Cuts Debugging Time to 5 Minutes and Reduces Observability Costs by 75%

Before adopting Honeycomb, Scribe relied on New Relic for observability. While functional, the platform became increasingly difficult for engineers to use and costly to operate.

The technical limitations were just as significant. Scribe lacked frontend-to-backend tracing, which made it impossible to follow a user request through the system. When incidents occurred, engineers searched raw logs for keywords across millions of records, with timestamps but no correlation between services.

Debugging often took up to an hour. During that time, customer-facing issues persisted and engineering focus fractured. Leadership recognized that this approach put customer experience and team productivity at risk.

Cost pressure added urgency. Scribe’s New Relic contract carried an annual commitment along with significant overages that were rapidly accumulating.

With renewal approaching and observability maturity lagging, the team began evaluating alternatives.

Scribe needed an observability platform that could:

• Provide end-to-end visibility across services
• Reduce time spent correlating logs and traces
• Support engineers directly during incidents
• Scale cost-effectively as usage grew

Scribe's move to Honeycomb also included a move to OpenTelemetry. The team wanted standardization, flexibility, and freedom from vendor lock-in.

With Honeycomb’s native OpenTelemetry support, Scribe had a clear path from proprietary instrumentation to open standards. The Honeycomb engineering team worked directly with Scribe to guide the transition and ensure smooth adoption across their services.

The result was a major milestone for the team: full frontend-to-backend tracing.

“Whenever a user clicks on a trace, they can see that whole workflow. With Honeycomb, we know exactly what part of the trace or where in our system is slowing that user down. If there are errors, we know exactly where they are,” explained Steven Tan, Senior DevOps Engineer at Scribe.

That visibility changed how engineers work and what they can solve:

• Frontend and backend traces connected in a single view
• Requests traced end to end without manual correlation
• Standardized instrumentation across services
• Faster identification of failing services
• Clear ownership during incidents
• High confidence troubleshooting issues

“When we have an incident, Honeycomb is our trusted source of truth. It's not even a question anymore—Honeycomb is where our investigations start," said Steven.

Instead of searching raw logs or bouncing between tools, engineers begin investigations with traces, then drill into logs and metrics as needed. Scribe organized telemetry into service- and product-specific datasets, so engineers know exactly where to look when an issue arises.

If a problem affects the AI service, they go to the AI dataset. Frontend issues start with load balancer and user-facing traces. This structure turns broad, time-consuming searches into targeted investigation. Engineers report that isolating the root cause now takes about five minutes, with high confidence in the results.

How debugging changed

Before

Broad log searches, little correlation

30-60 minutes to troubleshoot

After

Targeted datasets with traces as the entry point

5 minutes to isolate root cause

Scribe’s engineers adopted Honeycomb’s full depth of capabilities within months because they could apply it directly to real production questions without upfront configuration or rigid workflows. The engineers quickly began using queries, traces, dashboards, and alerts as part of their daily work.

That level of hands-on usage went beyond a single feature and reflected how Honeycomb fit into existing engineering practices. As usage grew, it also reshaped how engineers collaborate during incidents.

Honeycomb provides shared visibility into system behavior and the investigative steps engineers take to understand it. During incidents, the engineers share links to live queries, traces, and dashboards instead of screenshots or second-hand summaries. The History view captures how an investigation unfolded, which enables others to follow the same path, extend the analysis, and contribute without restarting the work.

“Sharing queries and traces changes how our engineers debug together. They can see the same data and act on it faster,” Steven highlighted.

As usage expanded, engineering teams developed their own Honeycomb champions. These engineers help others apply observability to their services and reinforce consistent practices across the organization.

One of the most significant shifts at Scribe is how early teams start thinking about observability. Before Honeycomb, observability was often treated as something to add later. Today, engineers think about traces, logs, and alerts while they're building.

When Scribe began developing Optimize, their newest product, feature teams approached DevOps early to ensure OpenTelemetry instrumentation and Honeycomb visibility would be ready at launch.

"Once engineers experience good observability with Honeycomb, there's no going back. Instrumentation ships with the code now. They won't have it any other way," Steven explained.

That mindset shift shows up in how the team builds:

• Instrumentation is part of the design
• Every environment gets the same visibility
• Alerts and dashboards ship with features

The result is in-depth visibility from day one and faster iteration once features go live.

Cost predictability was a critical requirement after Scribe's experience with runaway overages from their previous observability solution. Honeycomb Telemetry Pipeline plays a key role in maintaining control as observability usage grows.

Scribe uses tail-based sampling to manage log and trace volume while preserving the data engineers need during investigations. Sampling decisions happen in the pipeline, not at the application level, giving the team flexibility without re-instrumentation.

This approach supports scale while contributing to a 75% reduction in observability costs compared to their previous solution. The result is an observability practice that grows with the team, not against the budget:

• Predictable spend that the company can plan around
• Cost control that scales as more engineers adopt observability
• No tradeoff between visibility and budget—the team gets the insights they need without surprise bills

Expanding observability through MCP

As part of a broader internal push toward MCPs, Scribe’s engineers are actively integrating Honeycomb’s MCP support with Claude Code to investigate alerts and query system behavior conversationally.

“Our company is pushing MCPs, and Honeycomb is one of the first systems we’re using for that. Engineers love integrating MCP servers to ask about alerts and expanding our MCP adoption is a priority going forward,” Steven shared.

Earlier signals, fewer incidents

Scribe’s next phase focuses on moving from reactive incident response to proactive detection. The team also aims to expand how engineers interact with observability data.

Looking ahead, Scribe plans to reduce incident response time through earlier detection and clearer signals. The engineering organization expects to double in size by year’s end. Maintaining an observability-first culture remains a priority as new engineers join.

“We plan to keep maturing our observability practices as the team grows, and Honeycomb is a key part of that strategy. It helps us move faster while maintaining the quality and reliability our customers expect,” explained Steven.

1. Choose a tool that engineers want to use
   “Honeycomb is strong at what it’s meant to do: observability. There’s no extra noise, so engineers adopt it quickly.”
2. Use OpenTelemetry to stay flexible
   “Using open standards gives us confidence we won’t be locked in as our systems evolve.”
3. Build observability in from day one
   “Engineers think about how they'll observe a system with Honeycomb before they launch it; that’s not an afterthought anymore.”
4. Share context, not just alerts
   Engineers learn from each other's debugging work through Honeycomb's History tab, which accelerates team knowledge.