Alert Muting Schedules

Create a flexible alert muting system that enables customers to schedule downtime ahead of time or create ad hoc muting when necessary. The solution needed to reduce alert noise during planned maintenance while maintaining system monitoring so events occurring during muting periods could still be reviewed and analyzed after the fact.

Customers routinely faced periods of planned downtime — installing updates, performing maintenance, or responding to production issues. During these windows, their monitoring systems became a source of noise rather than insight.

The existing monitor configuration only allowed for completely disabling or enabling monitors. There was no way to set a temporary period of suppression, and no method to schedule downtime in advance. Worse, disabling a monitor meant activity was no longer tracked at all.

What customers needed was a way to reduce alert noise while maintaining system monitoring — so that events occurring during muting periods could still be reviewed and analyzed after the fact. The growing demand for this capability made it clear: we needed an alert muting feature that enabled customers to schedule downtime ahead of time or create ad hoc muting when necessary.

I was the lead designer working with Sumo Logic's alerting team—a product manager, senior engineering manager, front-end engineer, several backend engineers, and a QA engineer. Product management provided sparse requirements, leaving it largely to me and the engineering team to define the feature set.

The one firm requirement: feature parity with our existing scheduled search capability, including calendar definition and Recurrence Rules (RRules)—the standard scheduling method used in enterprise and consumer products like Google Calendar, Outlook, and Apple Calendar.

I worked with the alerting team — a product manager, senior engineering manager, front-end engineer, backend engineers, and QA — to define and deliver this feature. Product management provided a sparsely specified requirements document, leaving it largely to me and engineering to determine the available features, with one caveat: feature parity with the existing scheduled search capability.

In practical terms, this meant including a calendar definition feature and a method for configuring Recurrence Rules (RRules) — the standard method for scheduling used across both enterprise and consumer products like Google Calendar, Outlook, and Apple Calendar.

Pattern exploration

I began by reviewing similar features at competitors and consumer products, examining how they handled calendar events with repeatable or ad hoc configurations. We had two established patterns for exposing configurable objects: a simplified pattern that exposed configuration only from the list page, and a modal overlay pattern that enabled configuration from anywhere within the platform.

Given the relatively sparse number of configurable items, I initially chose the simplified pattern. This included a tabular list with single-item selection — upon selection, an information panel would slide into view on the right, scaling the table to accommodate. Users could click Edit to modify the object, then save or discard changes.

Evolving the approach

After presenting designs to the team, we mostly agreed on the approach — but the front-end engineer pushed back. He preferred the more complex modal overlay pattern, partly because he'd been using it exclusively and would need time to learn the simplified pattern's codebase.

After discussion with team leads, we agreed to expand scope and adopt the more sophisticated modal overlay pattern. I reconsidered the overall design, adding two significant features: a calendar preview that displayed selected dates for easy verification, and a scoping feature that automatically selected relevant items to mute from within the schedule configuration.

Comprehensive date handling

One of the key design decisions was how we handled end-of-month and leap year selections. After investigation, I developed a comprehensive selection pattern that allowed for selection of any days between the first and twenty-eighth of any month, with granularity ranging from hourly to four-year recurrence cycles.

Visual calendar feedback

The primary design affordance was the calendar display. When configuring schedules either manually or through RRule selection, users could see the calendar dynamically update and review their date selection without needing to calculate manually. This simple feedback mechanism offered easy confirmation — in user testing, it was specifically referenced as a welcome addition.

Flexible attachment model

The scoping feature enabled users to attach schedules to monitors in two directions: from the source object, or from the schedule itself. Users could add tags to different objects within the Sumo platform, then reference those tags with the scoping feature to automatically apply schedules to items within scope. They could also select schedules to attach from within the relevant object — including from multi-selected items.

This bidirectional approach expanded on the initial attachment model, where users would have been required to update configuration everywhere to enable schedule-based muting.

Customer feedback was universally positive. The feature was praised as simple to use and understand, validating the design direction we'd taken. Adoption met expectations, and we had a clear success on our hands.

However, the path to release wasn't without challenges. A cascade of issues with the scoping feature delayed release past its due date. Additional problems with the libraries selected to power the calendar visualizer caused further delays. Despite my protests and the universally positive user testing feedback, engineering management reduced scope at the last minute — the calendar preview was cut.

There was little I could or would change about my design approach — the feature was well received and delivered real value to customers. But I was disappointed with the outcome regarding the calendar preview, a feature that testing showed users genuinely appreciated.

This project taught me more about organizational dynamics. I realized I needed to be more effective as a user advocate — displaying more urgency in promoting features that deepen product value. Sometimes being right isn't enough; you have to fight harder for the details that matter.