Unified Monitoring & Alerting

Sumo Logic needed to transform its monitoring capabilities to retain customers and compete effectively against DataDog, Splunk, and New Relic. The goal wasn't just to build a better monitoring tool — it was to create an extensible foundation that would support the company's alerting ecosystem for years to come.

We set out to replace fragmented legacy tools with a unified platform that could gracefully accommodate future capabilities: outlier alerting, smart alerts, SLO monitoring, and eventually the Alert Response Platform.

Sumo Logic had built ad-hoc reporting tools that customers were using as makeshift monitoring and alerting solutions. These tools required deep understanding of Sumo's query language to fully exploit — and even experienced users often needed professional services interventions to achieve their desired outcomes.

The legacy scheduled search feature exemplified these problems. It was only available from the log search page, required complete configuration before deployment, hid settings across separate pages, and was notoriously difficult to find once set up. Users couldn't quickly create a simple monitor — they had to configure everything upfront or nothing at all.

A new team was formed specifically for this initiative. The core team included a Product Manager, Senior Staff Engineer, three front-end engineers, and more than a dozen back-end engineers. I served as the primary UX lead, with a junior designer reporting to me whom I mentored on the output message design component.

What I owned

• Competitive research leadership — Led research efforts with the PM, Sr. Staff Engineer, and other product leaders, analyzing DataDog, Splunk, and New Relic's monitoring solutions
• End-to-end design — Responsible for the entire design from concept through implementation, including new components (icons, modal design, and interactive elements)
• Framework architecture — Created the end-to-end UX framework that would guide future product development
• Design governance — Conducted regular UX review meetings with team leads and the extended team, with periodic reviews across the broader UX organization

We began by understanding current monitoring practices — both in the field and among our competitors. Through research reviews, customer interviews, and conversations with internal support teams, we learned what our customers were looking for and where we needed to focus.

Key research findings

• Customers wanted visual configuration — not just query-based setup
• Alert fatigue was a universal pain point across all platforms
• Integration with existing workflows (PagerDuty, Slack) was essential
• The system needed to scale from simple thresholds to complex ML-based detection

Three key design decisions shaped the monitoring system's success and established patterns that would guide future products.

Application-wide accessibility

Unlike previous feature implementations that siloed configuration to feature-specific pages, we made monitor configuration available across the entire Sumo Logic application.

Users could create and edit monitors from any search result, dashboard panel, or metrics exploration — and eventually from security dashboards and reports as well. This framework made it easy to extend the system to accommodate different monitor types as the platform evolved.

Severable configuration areas

We partitioned the modal into independent sections, enabling users to configure base monitor settings quickly and add complexity incrementally. A functioning, near-real-time monitor required only three things: a query, one trigger condition, and a name.

This was a stark contrast to legacy scheduled search, which necessitated complete configuration, hid sections across separate pages, and required all fields to be configured before deployment.

Simplified notifications

Notifications were completely reimagined. They became optional rather than required, easy to configure, and supported multiple notification channels simultaneously. Users could enable or disable individual notifications without affecting the rest of their configuration.

This flexibility meant teams could iterate on their alerting strategy without rebuilding monitors from scratch — a common frustration with the legacy system.

Upon release, unified monitoring was an immediate success. We measured steady growth and adoption from introduction, onboarding several large-scale enterprise customers who were able to effectively translate existing monitors from third-party solutions.

Customer feedback was generally positive, and the UI was universally well received. We extended feature capabilities significantly beyond what the original scheduled searches offered, without changing the foundational patterns.

If I could revisit this project, I would have pushed harder for a simplified trigger configuration design. Instead, I conceded to a natural language interface approach that others on the team advocated for. The NLP-based trigger configuration ended up being difficult to maintain and was the only part of the design that proved problematic over time.

This project also gave me a better understanding of stakeholder dynamics. I learned to identify which leaders could be relied upon to pursue better UX versus those for whom convenience and shipping velocity were paramount. That awareness has shaped how I navigate design decisions and build consensus in subsequent projects.