Release Incident Playbook

Deep link broken after routing change: symptoms, cause, and the test that catches it

Deep links or universal links open the wrong screen or nothing.

Deep link broken after routing change is documented by 2 accepted public reports from 2 organisations, 2 of them published in the last 5 years.

  • Likelihood: low (2 public reports in 5 years)
  • Impact: medium (2 of 2 reports: availability)

2 public reports · verified 2026-10-21

Symptoms

User-visible

  • Users who opened links from the deep linking service landed on the app's default fallback domain when one was configured.[2]
  • Users saw an error page when the app had no fallback domain configured.[2]
  • Some iOS users could not open the app in a same-device flow.[1]
  • Universal links did not open the app for users who installed it after the migration or whose iOS rechecked the site association file.[1]

Monitoring-visible

  • User reports that the app did not open on iOS started at 21:07 CEST on 29 June.[1]
  • The old app domain answered requests with a redirect to the new domain.[1]
  • Link redirection failed for 22 minutes after the configuration change.[2]

Root causes

  1. stage: config A configuration change in the deep linking service made link redirection start failing.[2]
  2. stage: infra The old app domain moved to a new DNS provider and redirected its traffic to the new domain. iOS does not follow redirects for universal links, so devices could not validate the site association.[1]

Public examples

Test classes that catch it

Test classStageLimitationBasis
End-to-end testspre-deployAn end-to-end test on a device that had already validated the site association still opens the app, because the failure hit only users who installed after the migration or whose iOS rechecked the association file.by design analysis
Synthetic monitoringpost-deployA synthetic browser check follows the redirect to the new domain and passes, so it misses the iOS segment that rejects redirects for universal links.by design analysis
Configuration and environment testspre-deployA configuration test finds the redirect only if it runs on the domain migration itself, because the DNS provider move happened outside any app release.by design analysis

Risk

  • Likelihood: low (2 public reports in 5 years)
  • Impact: medium (2 of 2 reports: availability)
Counts behind the grades
Accepted public reports2
Published in the last 5 years2
Impact stated: availability2

How the grades are computed

Pre-release checklist

  • PR-01
  • PR-02
  • PR-03
  • PR-04
  • PR-05
  • PR-06
  • PR-07

First 30 minutes

  • FM-01
  • FM-02
  • FM-03
  • FM-04
  • FM-05
  • FM-06
  • FM-07
  • FM-08

Download the checklist

What catches this: catalogue entries

Listed because their own documentation or site names end-to-end tests, synthetic monitoring, configuration and environment tests on the verification date. Alphabetical. Not a recommendation.

Tools whose documentation names these test classes

Providers whose site names these test classes

Only on this page

Deep link broken after routing change was not introduced in app code in either report. In report [1], the fault entered at the infrastructure stage through a domain migration. The old domain moved to a new DNS provider and redirected traffic to the new domain [1]. iOS does not follow redirects for universal links, so devices could not validate the site association [1].

In report [2], the fault entered through a configuration change in the link redirection service, and redirection failed for 22 minutes [2]. Neither fix needed a new app build. Report [1] changed the old domain's DNS settings back to the old server, and report [2] restored links while a links backup served fallback redirects.

Questions

What causes deep link broken after routing change?

In report [1], a domain migration redirected traffic to a new domain, and iOS does not follow redirects for universal links. In report [2], a configuration change made link redirection fail.

What are the symptoms of deep link broken after routing change?

Some iOS users could not open the app in a same-device flow [1]. Users who opened links reached the fallback domain or an error page during the 22 minutes of failed redirection [2].

Which test class catches deep link broken after routing change, and what does it miss?

End-to-end tests, synthetic monitoring and configuration tests are listed, all with the by-design label. An end-to-end test on a device that had already validated the site association still opens the app.

Which public reports document deep link broken after routing change?

Two primary reports from two organisations document it. They were published on 2022-06-22 [2] and 2025-07-01 [1].

How long did it take to detect deep link broken after routing change in the public reports?

Neither report states a time to detect in minutes. In report [1], the first user report arrived at 21:07 CEST on 29 June, and investigation started at 13:15 CEST on 30 June.

Should a team roll back or fix forward when deep link broken after routing change happens?

Report [1] pointed the old domain back to its original server and offered a page that converts old links. Report [2] restored links to full health 22 minutes after the change.

Release Incident Playbook (2026). Deep link broken after routing change: symptoms, cause, and the test that catches it, content version 1.0.0. https://releasefailures.com/incidents/deep-link-broken-after-routing-change/. Accessed 2026-10-21.