Follow a mobile failure to its backend request.

Check your installed version: this guide covers project connections in 3.7+ and enriched investigation in 3.8+. Documentation can update before application and SDK publication finishes. Confirm the required release is available before upgrading.

Enable related requests

Requires Logister 3.7 or later. The project picker below requires 3.7.1; verify the required SDK version is published before upgrading. You must manage both projects to connect them.

1. Set LOGISTER_CROSS_PROJECT_CORRELATIONS=true on your Logister instance. The default is off.
2. In each project, open Settings → Connections, select Find related requests for the project, and choose Save setting.
3. In the backend project, use Link an app to this backend. Choose the Android or iOS project from App project, then select Review connection. Check that the named mobile app sends requests to the correct backend. Select the App environment and Backend environment, then select Link projects. Repeat for your other mobile app. Starting from a mobile project instead shows Link this app to a backend.
4. Upgrade the relevant SDKs and enable the application's outbound HTTP wrapper with an exact backend-origin allowlist. Exclude mobile-token issuer URLs. Keep each app's own release and environment.

Project choices show the platform and slug to distinguish similar names. Only active projects you own or administer appear; already linked projects cannot be selected again. Environment lists show recent values and common names. Choose Other environment to enter a missing name exactly as your app reports it. Each linked project shows a reminder if related requests are still disabled.

Readers need access to both projects. A connection grants no permissions. Either project's manager can disconnect it.

Choose your SDK integration

Headers use W3C traceparent and x-request-id. URLSession, fetch, and HttpURLConnection wrappers return redirects for explicit handling. The OkHttp integration checks each redirect hop. Generic header helpers require disabled redirects or per-hop validation. Browser CORS must allow both header names.

Verify one failed request

1. Make a test call from the mobile app to its backend. Retain the wrapper's immutable request handle and attach it to the handled error.
2. Confirm the backend records the same trace ID with a new local span and the outgoing mobile span as its parent.
3. Open the mobile error occurrence and its Related requests panel. Open the matching backend occurrence.
4. Check the evidence label and release. A deployment is attached only when its own project, environment, and release identify exactly one preceding deployment.

These labels describe identifiers, not proof of causation. Endpoints and timestamps provide context; they do not create a match. Aggregate OS diagnostics and unrelated crashes are not assigned a guessed request.

CLI 1.2.0 adds the same lookup. Its token needs events:read, errors:read, traces:read, and deployments:read, plus both projects in its allowlist.

logister events correlations EVENT_UUID --project PROJECT_UUID --format json

Investigate connected impact (Logister 3.8+)

Open an error's Related requests panel to see captured HTTP outcome, duration scope, app version/build, device details and issue ownership. Open request follows the exact span. Each project keeps its own release and deployment identity.

1. Choose Inspect connected impact from Overview, Issues, Explore → Events, Performance (App health on mobile), or Releases. Once a project is linked, Explore → Connected opens the same report as a view of its own. In Issues, Show connected evidence adds badges for visible issues.
2. Select the environment, time window and connected project. Filter this project's release/build separately from the connected project's release/build. An issue link scopes the report to its retained occurrences.
3. Inspect observed request outcomes, captured P95 durations and affected installations/sessions within each mobile project. Identity coverage is shown; missing values are unknown.
4. From a deployment, choose Compare connected impact to inspect related errors before and after it. Exposure times are shown. Counts are not traffic-adjusted and do not prove a deployment caused or fixed an error.

Reports default to 24 hours and allow up to seven days. They inspect up to 500 recent anchor records, 500 candidates per signal per peer, 2,000 related pairs and 200 metric rows. Matches are within 15 minutes of each anchor. The screen shows the first 50 pairs; JSON exports keep the bounded pair set. Anchor metrics include unmatched inspected requests; peer metrics include matches only. Counts are observed evidence, not total traffic or unique people.

Failures count recorded errors or HTTP 4xx/5xx among known outcomes; P95 uses captured durations. Client and backend durations measure different work. Do not add or subtract them. Partial retention or limits are visible; a missing match does not prove success. Issue ownership and mobile identity counts require retained PostgreSQL evidence.

On Settings → Connections, Verify request evidence checks the mapped environment and peer for observed matches. No matching evidence does not certify a configuration problem; trigger a synthetic request to verify propagation.

Carry evidence into exports and notifications

Enable connected evidence when exporting an issue to include up to 50 related records from its latest retained occurrence. Existing error emails can include up to five related records visible to the recipient when the message is built. Each new report, download and delivery rechecks access; previously downloaded or emailed copies cannot be recalled.

Optional HTTP metadata

Android and iOS 0.6.1 add method, status code, failure category, attempt and duration scope. URLSession measures through the response body; HttpURLConnection through the caller's consumption callback; OkHttp through response headers. OkHttp captures DNS/connect failures before network interception, but does not count invisible transport retries or later body failures. No extra bodies, headers or user identities are sent. CLI 1.2.1 reviews the enriched response. Verify these release targets in their package channels before upgrading; older payloads remain readable.

If a related request is missing

• No panel: check the instance flag and this project's setting.
• No backend result: check access to both projects, both opt-in settings, environment mapping, outgoing headers, and the selected occurrence's IDs. Conflicting IDs are excluded.
• Incomplete results: check retention coverage and narrow the time range. The default is ±15 minutes; the maximum is 24 hours, ten connected projects, 500 rows, and 1 MiB of response metadata.
• No deployment: record the backend's own release/environment and deployment time. Missing or ambiguous releases are left unlinked.
• Unexpected match: disable related requests or disconnect the projects while checking identifier reuse. Incoming identifiers are untrusted metadata.

See CLI setup, GitHub source context, or report a documentation issue.