
<figure>
  <img src="/case-study-assets/status-pages-hero-light.png" alt="status-pages-hero-light.png: Our new Status Pages, as used by OpenAI and friends." />
  <figcaption>Our new Status Pages, as used by OpenAI and friends.</figcaption>
</figure>

### Context  
Incident.io provides tools for managing and communicating incidents, including hosted **status pages** used by companies like Linear, HashiCorp, Etsy and Square. These pages were already live in production for hundreds of paying customers and often used during outages, so stability and visual consistency were critical.  

In early 2023, **OpenAI committed to adopting our status pages**, bringing with them a huge audience: their existing Atlassian-hosted page had around **250,000 subscribers** — **10× more than our second-largest customer at the time**. It was a major opportunity and a reputational risk. But the pages hadn’t been touched in months and no team currently owned them.

### Problem  
The existing pages had drifted significantly from our design system. Years of small tweaks had created visual clutter: duplicate components, gradients, inconsistent spacing, and unclear hierarchy.  

Because **major customers were already using the pages**, the redesign had a strict constraint: it had to **modernise the experience without breaking trust or disrupting existing users**. These companies were historically very sensitive to visual change — any unexpected modification risked support tickets or frustration during an outage.

<figure>
  <img src="/case-study-assets/status-pages-before.png" alt="status-pages-before.png: Status Pages before: tired gradients and noticeable divergence from the rest of our product suite" />
  <figcaption>Before: tired gradients and noticeable divergence from our other products</figcaption>
</figure>

<figure>
  <img src="/case-study-assets/status-pages-after.png" alt="status-pages-after.png: Status Pages after: cleaner, brighter visuals and aligned with our design system" />
  <figcaption>After: cleaner, brighter visuals and aligned with our design system</figcaption>
</figure>

### Approach  
I began with a **UI audit**, mapping out misalignments, redundant styles and areas that deviated from our design system. The redesign focused on **clarity and neutrality**: removing decorative elements, standardising spacing, and creating a calm visual baseline that could sit comfortably beneath any customer’s brand.  

Most customers place their own logos at the top of the page, so the UI had to behave like **part of their identity**, not ours. This meant a **strictly monochrome palette**, with colour used sparingly for clear incident states (up, degraded, down).  

To enable long-term consistency, I rebuilt the theming system using **Figma variables**, so every component could switch between light and dark mode automatically — a major improvement to maintainability.  

Once the design was approved, I **paired with engineering** and contributed directly to the implementation using Cursor and AI-assisted refactors. This accelerated the rollout and helped maintain a high level of fidelity.

<figure>
  <img src="/case-study-assets/status-pages-components.png" alt="status-pages-components.png: Dozens of components have made it easier than ever to work on Status Pages" />
  <figcaption>Dozens of components have made it easier than ever to work on Status Pages</figcaption>
</figure>

<figure>
  <img src="/case-study-assets/status-pages-colors.png" alt="status-pages-colors.png: Figma variables made theming a breeze" />
  <figcaption>Figma variables made theming a breeze</figcaption>
</figure>

### Solution  
A clean, minimal, trustworthy status-page design that aligned with our design system, presented information clearly, and stayed visually neutral across customers. The new layout improved readability, simplified the hierarchy, and removed the visual “jank” that had accumulated over time.

<figure>
  <img src="/case-study-assets/status-pages-issues-light.png" alt="status-pages-issues-light.png: Active issue scren" />
  <figcaption>Active issue screen</figcaption>
</figure>

<figure>
  <img src="/case-study-assets/status-pages-resolved-light.png" alt="status-pages-resolved-light.png: Resolved issue screen" />
  <figcaption>Resolved issue screen</figcaption>
</figure>

<figure>
  <img src="/case-study-assets/status-pages-emails-light.png" alt="status-pages-emails-light.png: Active issue email" />
  <figcaption>Active issue email</figcaption>
</figure>


### Impact  
The redesign launched ahead of OpenAI’s rollout and was viewed by **hundreds of thousands of users** within the first weeks. Despite the sensitivity of our existing customer base — including **Linear, HashiCorp, Etsy and Square** — the launch resulted in **zero complaints**, demonstrating that we improved the product without disrupting expectations.  

Internal feedback was extremely positive, and the redesign became a reference point for customer-facing surfaces across Incident.io. It also strengthened trust with enterprise prospects and set the visual foundation for future product marketing surfaces.


Redesigned ahead of OpenAI's rollout, seen by hundreds of thousands within weeks.

incident.io

Status pages redesign


<figure>
  <img src="/case-study-assets/on-call-app-dark.png" alt="on-call-app-dark.png: Sample screens from the on-call app — switch theme to see light/dark examples" />
  <figcaption>Sample screens from the on-call app — switch theme to see light/dark examples</figcaption>
</figure>

## Context  
When I joined Incident.io, the company offered incident management tools focused on communication and coordination inside Slack. But customers still relied on third-party on-call products like PagerDuty and Opsgenie to route alerts — and they *hated* them.  

PagerDuty in particular was powerful but dated: complex configuration, clunky UX, and a mobile app that was notoriously painful to use. Many of our customers were actively asking, *“When are you going to build this too?”*  

Building our own on-call system was an enormous opportunity. PagerDuty is a billion-dollar business doing this one thing; if we could design something simpler, faster, and friendlier, we could unlock huge value for our users — and for the company.

## Problem  
On-call software touches every layer of an organisation: alert ingestion, routing, scheduling, escalation, and notifications. It’s technically deep and full of configuration edge-cases.

PagerDuty’s complexity allows it to handle every imaginable setup — but that same flexibility makes it painful to use day-to-day. Our challenge was to **re-imagine on-call from the ground up**: preserve the power, remove the pain.

## Approach  
We built a small, tight, cross-functional team of design, product, and engineering, and worked with a **handful of design-partner companies** who had volunteered to shape the product with us. We met weekly, shared designs and prototypes, gathered feedback, and onboarded them gradually as new features landed. This cadence gave us immediate validation that what we were building worked for real teams of different shapes and sizes.

I led design across the entire experience — from **alert sources and routing** through **escalation paths, schedules, and configuration UI**. There was an enormous amount to design quickly, so I focused on building a scalable design system early on, ensuring consistency across surfaces and helping engineering move fast.

Our goal wasn’t just to clone PagerDuty — it was to **improve it in almost every way**:
- **Smarter alert routes** that removed duplication (no more thousands of routes per service).
- **Intuitive scheduling** tools that made handovers easy to visualise.
- **A calm, modern interface** that reduced stress during incidents.
- **A genuinely useful mobile app** — fast, reliable, and designed to wake you up without overwhelming you.

<figure>
  <img src="/case-study-assets/on-call-alert-routes.png" alt="on-call-alert-routes.png: The new on-call interface showing schedules and alert routing" />
  <figcaption>The new on-call interface showing schedules and alert routing</figcaption>
</figure>

<figure>
  <img src="/case-study-assets/on-call-escalation-paths.png" alt="on-call-escalation-paths.png: The new on-call interface showing schedules and alert routing" />
  <figcaption>The new on-call interface showing schedules and alert routing</figcaption>
</figure>

## Collaboration  
I worked closely with PM and engineering throughout, co-creating prototypes and testing them with customers. Because I code, I could jump into the front-end where needed — giving precise feedback, fixing UI issues directly, and helping accelerate delivery.  
Our design-partner feedback loops meant the product evolved in lock-step with real usage: we could see what confused people, fix it, and ship again the same week.

## Multi-surface design  
Designing the experience meant orchestrating three key touchpoints:  
- **Web UI** — where admins configured schedules, escalation policies, and alert routing.  
- **Slack** — the heart of most incident discussions, so we deliberately “existed” where users already were.  
- **Mobile App** — the first mobile product Incident.io had ever built. It was designed to be *interruptive by necessity*, so I pushed early for light and dark modes to support use day and night.

<figure>
  <img src="/case-study-assets/on-call-touchpoints.png" alt="onc-touchpoints.png: Users interact with our product through many different touchpoints" />
  <figcaption>Users interact with our product through many different touchpoints</figcaption>
</figure>

## Solution  
A cohesive on-call platform with intuitive scheduling, visual escalation policies, and deep Slack integration — all underpinned by a cleaner, more rational configuration model.  
The design emphasised clarity, calm, and confidence. Every interaction was built to feel obvious, fast, and reliable — a deliberate contrast to the stress of traditional on-call tools.

<figure>
  <img src="/case-study-assets/on-call-schedules.png" alt="on-call-schedules.png: A simple example of an on-call schedule with multiple rotas" />
  <figcaption>A simple example of an on-call schedule with multiple rotas</figcaption>
</figure>

<figure>
  <img src="/case-study-assets/on-call-more-screens-light.png" alt="on-call-more-screens-light.png: Some more screens from the on-call app" />
  <figcaption>Some more screens from the on-call app</figcaption>
</figure>

## Impact  
The launch was a major milestone for the company. We hosted a public launch event, onboarded early customers like **Intercom**, and generated **$3m in revenue in our first year**. Adoption among existing “Response” customers exceeded targets, as many migrated away from PagerDuty and Opsgenie.  
Feedback from both customers and our design partners was consistently clear: *“It’s so much nicer and easier to use.”*  

The work established a new benchmark for how Incident.io designs complex, high-stakes products — setting the foundation for future enterprise growth and proving that thoughtful design can reshape even the most entrenched software category.

Generated $3m in its first year, competing directly with PagerDuty.

Sam Willis

About

Case studies

Connect