Linking Variables

We create a variety of links in our documentation, but the most commonly-used link type connects content either between product guides and the platform pages or between platform pages themselves. Each of these may take a different format, depending on whether a platform needs to be specified.

From Product to Platform

We use this format when linking from the product guides to the platform content because it allows the user to specify their platform, if it is not already specified. For example:

Releases also offer significant additional features when you fully [configure your SDK](/platform-redirect/?next=/configuration/releases/).

In the above example, when the user clicks the link to the releases configuration content, but hasn't yet visited a platform page, they will be asked to specify their platform so the page can be populated with the correct code sample when viewed. If they have navigated into product from the platform content, and are now navigating back into their platform, the platform context is maintained.

Within Platforms

We use this format when linking among or within the platform content:

You can set your own <PlatformLink to="/enriching-events/breadcrumbs/">breadcrumbs</PlatformLink> to make them more useful for debugging.

In the above example, when the user clicks the link to the breadcrumbs content, they will be navigated to the breadcrumbs content within their specific platform. If this link is used in product guides, and no platform is specified, the user will be navigated to the first platform listed, which is currently the Apple family of SDKs.

Hardcoding the Platform

We use this format when there's only one option for the platform, the content is not common to multiple platforms, or we want to force the reader to use this source of truth:

[NDK integration](/platforms/android/using-ndk/) is packed with the SDK and requires API level 16, though other levels are supported.

In the above example, there is only one place for users to learn about using Android's NDK, which is nested within the Android directory, so we can hardcode the path.

To Product Pages

We use this format when linking with our product content. Product guides do not currently need a platform to be specified. As a result, linking can define the path to the correct content in the product folder. For example:

You can also customize how events are grouped. Learn more about customized grouping in [Grouping Issues](/product/sentry-basics/guides/grouping-and-fingerprints/).

To External Pages

We use this format when linking to external pages. Most typically, this is to the UI:

The **Performance** page is the main view in [sentry.io](https://sentry.io) where you can search or browse for transaction data.

Anchor links (appended by the # symbol) further direct users to a specific section (rather than the general page).

Within the Same Page

We use this format to link users to content that's further down the page (typically beyond the initial fold):

On this page, you can control the frequency of your [email notifications](#notifications), [change your primary email](#emails), and update your security settings.

On Another Page

We use this format to direct users to a specific heading on another page:

To add to your quota or review what happens when you exceed it, see [Increasing Quotas](/product/accounts/quotas/#increasing-quotas).

This type of link can be used also for linking to anchors on external pages:

Sessions last for [Django's default session length](https://docs.djangoproject.com/en/1.11/topics/http/sessions/#using-cookie-based-sessions), which is two weeks.

Images

Images are maintained in the same folder as the content. This makes linking look like:

![Overview of Organization Stats page](org-stats-page.png)

Email address

We use this format when we want to link an email address (often used for Early Adopter or Beta features):

For more information about access to Metric Alerts, feel free to reach out at [alerting-feedback@sentry.io](mailto:alerting-feedback@sentry.io).

Help improve this content
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) to suggesting an update ("yeah, this would be better").