Deep link broken after routing change: pre-release and first 30 minutes checklists

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

The pre-release checklist maps each item to a test class from the incident page. The first-30-minutes checklist covers detection, containment, the rollback decision and customer communication.

7 pre-release items · 8 first-30-minutes items · verified 2026-10-21

Pre-release checklist

PR-01Before a domain migration, request the site association file on the old domain and confirm it is served directly with no redirect. config
PR-02Confirm every domain in the app's associated domains list still serves its own site association file after the DNS provider change. config
PR-03Run each change to the link redirection configuration against a list of sample links and their expected destinations before applying it. config
PR-04Install the app fresh on an iOS device after the domain change, open a universal link from the old domain and confirm the app opens on the linked screen. e2e
PR-05Open a sample deep link for each route and confirm it lands on the linked destination, not on the fallback domain or an error page. e2e
PR-06Schedule a check that fetches the site association file from each associated domain without following redirects and alerts on any redirect response. synthetic
PR-07Schedule a check that resolves a sample deep link through the redirection service and alerts when the final destination is the fallback domain or an error page. synthetic

First 30 minutes

FM-01Collect user reports of links that fail to open the app and note the OS, the install date and the link domain.
FM-02Request the site association file from the link domain and check whether it returns a redirect.
FM-03List recent DNS, domain and link redirection configuration changes, including DNS provider moves made outside the app release.
FM-04Point the old domain back to its original server so devices can validate the site association again.
FM-05Revert the link redirection configuration change if links land on the fallback domain or an error page.
FM-06Publish a workaround page that converts old-domain links into links on a domain that still opens the app.
FM-07Hold any emergency app store release until the domain and link configuration checks are complete.
FM-08Post a status update that names the affected platform, such as iOS, the affected flow and the workaround link.

Download the checklist

Pre-release checklist (Markdown)1.6 KB · v1.0.0
First 30 minutes checklist (Markdown)1.2 KB · v1.0.0

Only in this checklist

Every test class in this checklist also appears in at least one sibling checklist in the group; the item texts differ: Before a domain migration, request the site association file on the old domain and confirm it is served directly with no redirect.

Questions

What should be checked before a release to prevent Deep link broken after routing change?

7 pre-release items, PR-01 to PR-07. PR-01: Before a domain migration, request the site association file on the old domain and confirm it is served directly with no redirect.

Is there a rollback plan for Deep link broken after routing change?

The first-30-minutes checklist has 8 items. FM-01: Collect user reports of links that fail to open the app and note the OS, the install date and the link domain.

What should a team do in the first 30 minutes after Deep link broken after routing change is detected?

The first-30-minutes checklist has 8 items. FM-01: Collect user reports of links that fail to open the app and note the OS, the install date and the link domain.

Which configuration checks apply to Deep link broken after routing change?

PR-01: Before a domain migration, request the site association file on the old domain and confirm it is served directly with no redirect. PR-02: Confirm every domain in the app's associated domains list still serves its own site association file after the DNS provider change. PR-03: Run each change to the link redirection configuration against a list of sample links and their expected destinations before applying it.

Is a Deep link broken after routing change checklist still needed if deployment is automated?

Yes. Automation runs the steps; the checklist names what the tests must cover: configuration and environment tests, end-to-end tests and synthetic monitoring.

Which pipeline stages does the Deep link broken after routing change checklist cover?

The pre-release items map to the pre-deploy and post-deploy stages.