# How Compass Digital ruled out a false lead after recovery.

In a recent alert, Compass Digital investigated a sign-in issue that appeared soon after an infrastructure change. Anyshift ruled out that change and traced the issue to a shared SSO dependency outside the application.

Author: Anyshift

Published: 2026-09-03

Source: https://anyshift.io/blog/compass-digital-login-outage

## TL;DR

[Compass Digital](https://www.compassdigital.io/) builds technology for [Compass Group North America](https://www.compass-usa.com/), part of one of the world's leading food and support services companies. It uses [Anyshift](https://www.anyshift.io/) to connect **change history, cloud state, code, telemetry, and Slack** so engineers can investigate from one place. During an incident:

- **Anyshift ruled out the obvious suspect.** The issue followed an infrastructure change, but the dependency path showed that the change did not affect sign-in. **A rollback would not help.**
- **Anyshift isolated the real failure domain.** The production graph traced **application sign-in → external authorization → shared single sign-on service (SSO)**. Telemetry showed traffic stopping at the SSO boundary and resuming after recovery. **The service owner confirmed an outage during an upgrade.**

![Timeline showing how the recent change was cleared, incident-time evidence isolated shared SSO, and a later healthy check only showed recovery.](/images/blog/compass-digital-temporal-evidence.svg?v=17)

## A recent infrastructure change looked responsible for the sign-in issue.

The alert reported a sign-in issue in a development environment shortly after infrastructure pull requests merged. Two explanations were plausible:

- **The recent change affected sign-in.** The pull requests involved [GitHub Actions OpenID Connect](https://docs.github.com/en/actions/concepts/security/openid-connect) (OIDC), so the timing and identity context made them an obvious suspect.
- **A separate sign-in dependency failed.** Application sign-in used a different identity mechanism, but that separation was not yet proven.

**Both events involved identity and appeared close together. Before rolling back, the team needed to know whether they shared the same dependency path.**

A rollback would only help if the change touched the affected path. Otherwise, it would introduce another change without addressing the issue.

## An Anyshift graph query ruled out the obvious suspect.

The team needed two answers:

- **Where did the sign-in request stop?**
- **Did the recent change touch that dependency?**

A Compass Digital engineer asked Annie to run a [root-cause analysis](https://docs.anyshift.io/pages/product/root_cause_analysis). Annie connected the incident report with the [Anyshift production graph](https://docs.anyshift.io/pages/overview), code, cloud state, telemetry, and Slack.

![The Anyshift graph separates the recent CI/CD identity change from the application sign-in lineage that reaches shared SSO.](/images/blog/compass-digital-investigation-schema.svg?v=10)

Anyshift established that:

- **The login path crossed an external SSO boundary.**
- **The GitHub changes only affected continuous integration and deployment**, not application sign-in.
- **[AWS](https://docs.anyshift.io/pages/integration/aws) showed no relevant deployment or configuration change** on that path.

**The change and the issue were close in time, but not on the same path. That ruled out rollback.** It did not yet prove what had happened inside the shared SSO service.

## Events in the Anyshift graph pointed to shared SSO.

The same sign-in symptom could come from the application or its shared SSO dependency. Each possibility required a different response.

- **The Anyshift graph showed where and when:** [Dynatrace distributed traces](https://docs.dynatrace.com/docs/observe/application-observability/distributed-traces/concepts) were placed on the sign-in dependency path. Traffic stopped at the shared SSO boundary during the incident and resumed after recovery.
- **The SSO service owner explained why:** the shared service had been temporarily unavailable during an upgrade.

The [Anyshift graph](https://docs.anyshift.io/pages/overview) made these events useful by connecting each observation to the relevant dependency and incident window.

**Anyshift isolated the external SSO boundary and cleared Compass Digital's changes.**

## The Anyshift graph preserved the incident after recovery.

By the time the team investigated, the SSO endpoint was responding again. A graph that stored only current state would show a healthy dependency and lose the interruption that explained the sign-in issue.

Anyshift kept the relevant events on the dependency path with their timestamps:

- **Interruption:** authentication traffic stopped at the shared SSO boundary.
- **Recovery:** traffic resumed, and the endpoint later responded normally.

Topology explains **where a request goes**. Events explain **what happened on that path, and when**. Together, they let Compass Digital query the incident window instead of treating current health as proof of past health.

**The graph kept the recovered incident investigable.**

## Compass Digital avoided rollback by checking both path and time.

Compass Digital left the incident with more than an explanation. The team made a safer decision in the moment and kept a verified starting point for the next investigation:

- **A valid infrastructure change stayed in place.** The team avoided the additional risk and validation work of an unrelated rollback.
- **Attention moved to the right dependency.** Path and incident-time evidence pointed to shared SSO, giving its owner a precise issue to confirm.
- **The investigation became reusable.** Annie saved the confirmed cause and the temporal lesson, so a similar sign-in issue can start with historical SSO traffic instead of the nearest change.

**The service had already recovered; the investigation mattered because it protected a valid change, focused follow-up on the right service, and gave Compass Digital a stronger starting point for future incidents.**