<JB />
Joshua BusseyProduct Designer
LinkedIn
Work/Integrations with failing status checks

Integrations with failingstatus checks.

An expired cert during a live incident eroded customer trust. I designed the surface that surfaces brokenness before customers notice.

Project metadata
Client
Red Canary
Role
Senior Product Designer
Team
1 PM · 2 Eng · 1 Designer
Shipped
Q1 2025
Type
Design AdvocacyUX Loopholes
Result
~25% fewer support escalations

Friction

— Pain points for the customer
  • ↗Customers did not know why an integration suddenly failed to send data.
  • ↗Failing integrations created a major security risk while customers remained unaware of the health problem.

My Role

— What I owned during the process
  • ↗Advocated for a proactive solution instead of waiting for support to absorb the damage.
  • ↗Designed the notification and status UX so the messaging was clear, actionable, and hard to miss.

Outcome

— What I shipped
  • ↗Increased transparency and reduced support tickets.
  • ↗Strengthened customer trust in Red Canary's reliability.
  • ↗Established a pattern for proactive alerting elsewhere in the product.
The TL;DR.

Summary

I designed a proactive notification system for failing integrations so customers could see problems in real time instead of discovering them during an incident. The solution reduced support load, improved troubleshooting, and strengthened trust in the platform's reliability.

Failures were happening. Customers were blind.

The Problem

Failing integrations and expired certificates were creating real security posture risk, but customers were not being told clearly when an integration had stopped working.

That gap drove support requests, slowed troubleshooting, and made the platform feel less trustworthy right when customers needed it most.

Key Decision
"To toast or not to toast?"
A small notification would have been cheap to build, but the real question was whether a toast was enough for something this important.
Put integration health directly in context so customers can see what is broken, why it matters, and what action they should take next.
Health that is hard to miss.

The Solution

This was less about inventing a brand-new pattern and more about assembling the right existing pieces into a system customers could actually trust.

01

Flag health in the list view

A new status badge on the integrations list page made it immediately obvious which integrations needed attention.

02

Show failing checks in context

The integration detail page gained a dedicated status-checks area so customers could inspect the exact failing checks instead of guessing.

03

Always include an action

Contextual help and plain-language messaging gave users a clear next step instead of just telling them something was broken.

Two weeks. A small team.

The Process

Exploration

Exploration

Two weeks of runway meant the wireframes had one job — find where a health badge could live in the integrations list without adding noise.

Badge placement in context
Where a health badge could sit in the integrations list, and how much a failing-checks tooltip has to say to be worth stopping for.
Step 01

Call out the gap

The project started with a simple observation: a serious product health issue was going mostly unaddressed, even though the fix was within reach.

Step 02

Reuse a new surface

We had just introduced a new section on integration pages, so I used that momentum to extend it with a status-checks tab instead of inventing a new destination.

Step 03

Pair signal with guidance

The list badge and the detail-page checks worked together so users could spot a problem fast and then understand what needed to happen next.

Shipped

Two weeks of work, live in the product.

A sub-status for "active but broken"
An integration can be active and still failing its checks. The list now says so, and the tooltip explains what it means for ingest.
Failures sorted to the top
A banner on the config page whenever issues exist, and a Status Checks tab listing each check with its result and how long it has been that way.
What worked. What got tricky.

Reflection

Tough spots

  • The alert had to be visible without making users panic.

  • The status-checks area was already important but overlooked, so the design had to pull attention there intentionally.

  • A low-cost fix still needed enough depth to solve the trust problem, not just decorate it.

What went right

  • Buy-in was easy because the gap was obvious and the effort was relatively low.

  • Design review moved smoothly once the failure states were made concrete.

  • The work created a reusable pattern for proactive alerting in the platform.

Previous
Red Canary - 2025
Reimagining identity profiles with AI-driven insights
Next
Red Canary - 2024
Unified integration onboarding