getsentry · markstory · Oct 24, 2024 · Oct 18, 2024 · Oct 18, 2024 · Oct 19, 2024
diff --git a/develop-docs/application/config.mdx b/develop-docs/application/config.mdx
@@ -1,5 +1,6 @@
 ---
 title: Configuration
+sidebar_order: 60
 ---
 
 This document describes configuration available to the Sentry server itself.

diff --git a/develop-docs/backend/control-silo.mdx → develop-docs/application/control-silo.mdx b/develop-docs/backend/control-silo.mdx → develop-docs/application/control-silo.mdx
@@ -1,5 +1,6 @@
 ---
 title: Control Silo
+sidebar_order: 30
 ---
 
 Within the Control Silo are features that allow us to provide backwards compatibility for both customer API usage, and integrations

diff --git a/...docs/backend/cross-region-replication.mdx → .../application/cross-region-replication.mdx b/...docs/backend/cross-region-replication.mdx → .../application/cross-region-replication.mdx
@@ -1,5 +1,6 @@
 ---
 title: Cross Region Replication
+sidebar_order: 40
 ---
 
 Our data-model includes many relations between users and the objects they create or interact with. Eventually users are deleted, and they need to be detached from the records they created, or those records need to be destroyed. Before sentry became a multi-region application, we relied on a mixture of Django callbacks, and postgres constraints to cascade deletions. However, in a multi-region state we arent't able to rely on these anymore as Users are in [Control Silo](/architecture/#silo-modes) and many of the objects they interact with are in the various Region Silos.

diff --git a/develop-docs/backend/cross-region-rpc.mdx → ...lop-docs/application/cross-region-rpc.mdx b/develop-docs/backend/cross-region-rpc.mdx → ...lop-docs/application/cross-region-rpc.mdx
@@ -1,5 +1,6 @@
 ---
 title: Cross Region RPC
+sidebar_order: 50
 ---
 
 When Sentry is deployed in a multi-region deployment (like sentry.io) there are many scenarios and workflows where a region silo requires information that is stored in Control Silo. Similarly there are flows where Control Silo operations need to read or mutate state stored in regions.

diff --git a/develop-docs/application/dynamic-sampling/index.mdx b/develop-docs/application/dynamic-sampling/index.mdx
@@ -1,7 +1,7 @@
 ---
 title: Dynamic Sampling
 description: Dynamic Sampling is a feature of the ingestion pipeline that allows Sentry to automatically adjust the amount of data retained based on the value of the data.
-sidebar_order: 50
+sidebar_order: 10
 ---
 
 From all the data received by the SDKs, Sentry is able to extract low-granularity information through metrics, while Dynamic Sampling makes the decision of whether to keep or drop data.

diff --git a/develop-docs/application/feedback-architecture.mdx b/develop-docs/application/feedback-architecture.mdx
@@ -1,5 +1,6 @@
 ---
 title: User Feedback Architecture
+sidebar_order: 20
 ---
 
 **The goal of this doc is to give engineers an in-depth understanding of User Feedback's backend.**

diff --git a/develop-docs/application/sentry-vs-getsentry.mdx b/develop-docs/application/sentry-vs-getsentry.mdx
@@ -1,5 +1,6 @@
 ---
 title: sentry vs. getsentry
+sidebar_order: 70
 ---
 
 You'll find numerous references to both `sentry` and `getsentry` in our documentation. Both are [Django](https://www.djangoproject.com/) apps, but `sentry` [is open](https://github.com/getsentry/sentry) and `getsentry` is closed. What's in which?
@@ -10,7 +11,7 @@ So what's in `getsentry`, then? It implements billing and account management fea
 
 Additionally, `sentry` has many hooks, implemented using Django signals, which `getsentry` subscribes to. For example, there's a Django signal called `event_received` in `sentry` that is triggered when an event is saved. If you're [running self-hosted](/self-hosted/), nothing is subscribed to this hook. But in `getsentry`, we have a counter for billing that runs when that signal fires.
 
-There are also some swappable backends in `sentry` that `getsentry` utilizes, such as `sentry.nodestore`, `sentry.quotas`, and a home-grown feature flagging system. As with hooks, these modular backends are technically available to self-hosted instances, but they're largely undocumented. For example, the feature-flagging system has a hardcoded table of features ([`SENTRY_FEATURES`](https://github.com/getsentry/sentry/blob/master/src/sentry/features/__init__.py)) that [self-hosted installs can use](/feature-flags/) to control feature availability. `getsentry` registers a different feature flag handler that flips flags based on our [billing plans](https://sentry.io/pricing/) and early access program.
+There are also some swappable backends in `sentry` that `getsentry` utilizes, such as `sentry.nodestore`, `sentry.quotas`, and a home-grown feature flagging system. As with hooks, these modular backends are technically available to self-hosted instances, but they're largely undocumented. For example, the feature-flagging system has a hardcoded table of features ([`SENTRY_FEATURES`](https://github.com/getsentry/sentry/blob/master/src/sentry/features/__init__.py)) that [self-hosted installs can use](/backend/feature-flags/) to control feature availability. `getsentry` registers a different feature flag handler that flips flags based on our [billing plans](https://sentry.io/pricing/) and early access program.
 
 ## Notes for Sentry Engineers
 

diff --git a/...lop-docs/application/ab-testing/index.mdx → develop-docs/backend/ab-testing/index.mdx b/...lop-docs/application/ab-testing/index.mdx → develop-docs/backend/ab-testing/index.mdx
@@ -1,5 +1,6 @@
 ---
 title: A/B Tests with Amplitude
+sidebar_order: 190
 ---
 
 ## Why AB testing?

diff --git a/develop-docs/application/api/basics.mdx → develop-docs/backend/api/basics.mdx b/develop-docs/application/api/basics.mdx → develop-docs/backend/api/basics.mdx
diff --git a/develop-docs/application/api/checklist.mdx → develop-docs/backend/api/checklist.mdx b/develop-docs/application/api/checklist.mdx → develop-docs/backend/api/checklist.mdx
diff --git a/develop-docs/application/api/concepts.mdx → develop-docs/backend/api/concepts.mdx b/develop-docs/application/api/concepts.mdx → develop-docs/backend/api/concepts.mdx
diff --git a/develop-docs/application/api/design.mdx → develop-docs/backend/api/design.mdx b/develop-docs/application/api/design.mdx → develop-docs/backend/api/design.mdx
@@ -2,6 +2,7 @@
 title: Designing a New API
 sidebar_order: 2
 ---
+
 [Django REST framework](https://www.django-rest-framework.org/)(DRF) is a powerful and flexible toolkit
 for building Web APIs. Sentry APIs are built using DRF. Here are some considerations to make when designing APIs at Sentry.
 

diff --git a/develop-docs/application/api/index.mdx → develop-docs/backend/api/index.mdx b/develop-docs/application/api/index.mdx → develop-docs/backend/api/index.mdx
@@ -1,5 +1,6 @@
 ---
 title: API Development
+sidebar_order: 1
 ---
 
 As a developer-facing company it's critical for us to have simple, intuitive, and consistent APIs that our users can call from their dev environment to accomplish key tasks without going to the UI. If you're creating or editing an endpoint, this doc will help you achieve Sentry standards.

diff --git a/develop-docs/application/api/public.mdx → develop-docs/backend/api/public.mdx b/develop-docs/application/api/public.mdx → develop-docs/backend/api/public.mdx
@@ -56,7 +56,7 @@ As a guide, use these questions:
 2. Will the API change substantially in the future?
 
 If your answers are Yes and No, you're in business - make the endpoint public. Head over to the
-[public API checklist](/application/api/checklist/) and ensure that your endpoint conforms to the checklist.
+[public API checklist](/backend/api/checklist/) and ensure that your endpoint conforms to the checklist.
 
 ## Publishing an API
 

diff --git a/develop-docs/application/serializers.mdx → develop-docs/backend/api/serializers.mdx b/develop-docs/application/serializers.mdx → develop-docs/backend/api/serializers.mdx
@@ -1,5 +1,6 @@
 ---
 title: Serializers
+sidebar_order: 10
 ---
 
 Serializers are used to take complex python models and translate them into json. Serializers can also be used to deserialize json back to the python models after validating the incoming data.

diff --git a/develop-docs/services/buffers.mdx → develop-docs/backend/buffers.mdx b/develop-docs/services/buffers.mdx → develop-docs/backend/buffers.mdx
@@ -1,5 +1,6 @@
 ---
 title: Write Buffers
+sidebar_order: 170
 ---
 
 Sentry manages database row contention by buffering writes and flushing bulk changes to the database over a period of time. This is extremely helpful if you have high concurrency, especially if they’re frequently the same event.

diff --git a/...ns/img/post-deploy-pipeline-materials.png → ...ns/img/post-deploy-pipeline-materials.png b/...ns/img/post-deploy-pipeline-materials.png → ...ns/img/post-deploy-pipeline-materials.png
diff --git a/...rations/img/post-deploy-pipeline-tile.png → ...rations/img/post-deploy-pipeline-tile.png b/...rations/img/post-deploy-pipeline-tile.png → ...rations/img/post-deploy-pipeline-tile.png
diff --git a/...ns/img/post-deploy-pipeline-variables.png → ...ns/img/post-deploy-pipeline-variables.png b/...ns/img/post-deploy-pipeline-variables.png → ...ns/img/post-deploy-pipeline-variables.png
diff --git a/...development/database-migrations/index.mdx → ...ocs/backend/database-migrations/index.mdx b/...development/database-migrations/index.mdx → ...ocs/backend/database-migrations/index.mdx
diff --git a/develop-docs/backend/development-server.mdx b/develop-docs/backend/development-server.mdx
@@ -1,5 +1,6 @@
 ---
 title: Backend Development Server
+sidebar_order: 10
 ---
 
 (*see also: [Frontend Development Server](/frontend/development-server/)*)

diff --git a/develop-docs/services/digests.mdx → develop-docs/backend/digests.mdx b/develop-docs/services/digests.mdx → develop-docs/backend/digests.mdx
@@ -1,5 +1,6 @@
 ---
 title: Notification Digests
+sidebar_order: 140
 ---
 
 Sentry provides a service that will collect notifications as they occur and schedule them for delivery as aggregated “digest” notifications.

diff --git a/develop-docs/services/email.mdx → develop-docs/backend/email.mdx b/develop-docs/services/email.mdx → develop-docs/backend/email.mdx
@@ -1,5 +1,6 @@
 ---
 title: Email
+sidebar_order: 110
 ---
 
 Sentry provides support for both outbound, and incoming email.

diff --git a/...cs/application/feature-flags/flagpole.mdx → ...p-docs/backend/feature-flags/flagpole.mdx b/...cs/application/feature-flags/flagpole.mdx → ...p-docs/backend/feature-flags/flagpole.mdx
diff --git a/...-docs/application/feature-flags/index.mdx → develop-docs/backend/feature-flags/index.mdx b/...-docs/application/feature-flags/index.mdx → develop-docs/backend/feature-flags/index.mdx
@@ -1,5 +1,6 @@
 ---
 title: 'Feature Flags'
+sidebar_order: 40
 ---
 
 Feature flags are declared in Sentry's codebase (look for `SENTRY_FEATURES` in
@@ -67,7 +68,7 @@ be included in the results of the organization details response.
 
 ### Add your feature to the FeatureManager
 
-If you want to back your feature flag via options, you can do so using the [Flagpole](/feature-flags/flagpole/) library
+If you want to back your feature flag via options, you can do so using the [Flagpole](/backend/feature-flags/flagpole/) library
 by adding the feature to the `FeatureManager` with the `FLAGPOLE` enum set as the feature strategy:
 
 ```python
@@ -184,7 +185,7 @@ SENTRY_FEATURES['organizations:test-feature'] = True
 ```
 
 Alternatively, you can test Flagpole features by setting custom options locally.
-See the [Flagpole Local Development](/feature-flags/flagpole/#testing-a-flagpole-feature-locally) docs for more information on this.
+See the [Flagpole Local Development](/backend/feature-flags/flagpole/#testing-a-flagpole-feature-locally) docs for more information on this.
 
 ## Enabling your feature in production
 
@@ -193,7 +194,7 @@ flags are then configured via `sentry.conf.py`. For Sentry's SaaS deployment,
 you have the choice of using an option backed rollout via Options Automator with Flagpole,
 or by writing a custom feature flag handler.
 
-- [Flagpole](/feature-flags/flagpole/) is Sentry's internal feature flagging library, allowing a feature
+- [Flagpole](/backend/feature-flags/flagpole/) is Sentry's internal feature flagging library, allowing a feature
   with multiple target segments and condition filters to be defined in YAML within Options Automator.
 
 - [Options based features](options-backed-features/) [DEPRECATED] allow a feature

diff --git a/...feature-flags/options-backed-features.mdx → ...feature-flags/options-backed-features.mdx b/...feature-flags/options-backed-features.mdx → ...feature-flags/options-backed-features.mdx
@@ -4,7 +4,7 @@ title: Options Backed Features [DEPRECATED]
 
 Options backed features using the `OPTIONS` strategy enum were a temporary stopgap
 that was used to formalize options-backed feature flags. These have since been
-replaced by [Flagpole](/feature-flags/flagpole/), which is Sentry's preferred
+replaced by [Flagpole](/backend/feature-flags/flagpole/), which is Sentry's preferred
 means of setting feature flags now.
 
 

diff --git a/develop-docs/application/grouping.mdx → develop-docs/backend/grouping.mdx b/develop-docs/application/grouping.mdx → develop-docs/backend/grouping.mdx
@@ -1,5 +1,6 @@
 ---
 title: Grouping
+sidebar_order: 60
 ---
 
 Sentry has an extensive grouping system ([public documentation](https://docs.sentry.io/product/sentry-basics/grouping-and-fingerprints/))

diff --git a/...g/issuePlatformAdminDetectionSettings.png → ...g/issuePlatformAdminDetectionSettings.png b/...g/issuePlatformAdminDetectionSettings.png → ...g/issuePlatformAdminDetectionSettings.png
diff --git a/...issuePlatformCustomerDetectorSettings.png → ...issuePlatformCustomerDetectorSettings.png b/...issuePlatformCustomerDetectorSettings.png → ...issuePlatformCustomerDetectorSettings.png
diff --git a/...PlatformDbonMainThreadDetectorSetting.png → ...PlatformDbonMainThreadDetectorSetting.png b/...PlatformDbonMainThreadDetectorSetting.png → ...PlatformDbonMainThreadDetectorSetting.png
diff --git a/...ors/img/issuePlatformFingerprinting01.png → ...ors/img/issuePlatformFingerprinting01.png b/...ors/img/issuePlatformFingerprinting01.png → ...ors/img/issuePlatformFingerprinting01.png
diff --git a/...ors/img/issuePlatformFingerprinting02.png → ...ors/img/issuePlatformFingerprinting02.png b/...ors/img/issuePlatformFingerprinting02.png → ...ors/img/issuePlatformFingerprinting02.png
diff --git a/...ors/img/issuePlatformFingerprinting03.png → ...ors/img/issuePlatformFingerprinting03.png b/...ors/img/issuePlatformFingerprinting03.png → ...ors/img/issuePlatformFingerprinting03.png
diff --git a/...cation/issue-platform-detectors/index.mdx → ...ackend/issue-platform-detectors/index.mdx b/...cation/issue-platform-detectors/index.mdx → ...ackend/issue-platform-detectors/index.mdx
@@ -1,8 +1,9 @@
 ---
 title: Issue Platform - Writing Detectors
+sidebar_order: 90
 ---
 
-Issue detectors identify application issues by examining one or more datasets collected by Sentry, and report detected issue occurrences via the <Link to="/issue-platform/">Issue Platform</Link>. Detectors must fingerprint issues accurately and provide actionable information to developers.
+Issue detectors identify application issues by examining one or more datasets collected by Sentry, and report detected issue occurrences via the <Link to="/backend/issue-platform/">Issue Platform</Link>. Detectors must fingerprint issues accurately and provide actionable information to developers.
 
 # Considerations
 

diff --git a/...on/issue-platform/img/issueProperties.jpg → ...nd/issue-platform/img/issueProperties.jpg b/...on/issue-platform/img/issueProperties.jpg → ...nd/issue-platform/img/issueProperties.jpg
diff --git a/...docs/application/issue-platform/index.mdx → ...lop-docs/backend/issue-platform/index.mdx b/...docs/application/issue-platform/index.mdx → ...lop-docs/backend/issue-platform/index.mdx
@@ -1,5 +1,6 @@
 ---
 title: Issue Platform
+sidebar_order: 80
 ---
 
 The Issue Platform allows developers to create new issue types from arbitrary data sources. If you have data about something that you want to track via an issue, you can build it on the issue platform. For example, building profiling issues on the issue platform allowed us to turn things like “JSON decoding on the main thread” into their own issue types.
@@ -15,7 +16,7 @@ To use the Issue Platform you need to:
 
 The first step to introducing a new issue type to Sentry is to determine what type of issue you want to detect. It can be from any data stream, as long as you can produce an <Link to="#issue-occurrence-schema">Occurrence</Link> representing the issue.
 
-Writing a detector is the hardest part of creating a new issue type. Refer to <Link to="/issue-platform-detectors/">this guide</Link> for tips on how to write one.
+Writing a detector is the hardest part of creating a new issue type. Refer to <Link to="/backend/issue-platform-detectors/">this guide</Link> for tips on how to write one.
 
 ## Register an Issue Type
 

diff --git a/develop-docs/backend/kafka.mdx b/develop-docs/backend/kafka.mdx
@@ -1,5 +1,6 @@
 ---
 title: Kafka consumers
+sidebar_order: 110
 ---
 
 ## Creating a new consumer in Sentry

diff --git a/develop-docs/services/metrics.mdx → develop-docs/backend/metrics.mdx b/develop-docs/services/metrics.mdx → develop-docs/backend/metrics.mdx
@@ -1,5 +1,6 @@
 ---
 title: Metrics
+sidebar_order: 120
 ---
 
 Sentry provides an abstraction called ‘metrics’ which is used for internal monitoring, generally timings and various counters.

diff --git a/develop-docs/services/nodestore.mdx → develop-docs/backend/nodestore.mdx b/develop-docs/services/nodestore.mdx → develop-docs/backend/nodestore.mdx
@@ -1,5 +1,6 @@
 ---
 title: Node Storage
+sidebar_order: 130
 ---
 
 Sentry provides an abstraction called ‘nodestore’ which is used for storing key/value blobs.

diff --git a/develop-docs/backend/options/index.mdx b/develop-docs/backend/options/index.mdx
@@ -1,5 +1,6 @@
 ---
 title: Options
+sidebar_order: 50
 ---
 
 Options are a way to store generic system-wide configuration. They serve a similar purpose to configuration files, but they are backed by a database, so it's possible to change them at runtime without a deploy. Options are stored in the database and cached, so they are performant and reliable. This makes options well-suited for rates, quotas, and limits.

diff --git a/develop-docs/backend/outboxes.mdx b/develop-docs/backend/outboxes.mdx
@@ -1,5 +1,6 @@
 ---
 title: Outboxes
+sidebar_order: 70
 ---
 
 Outboxes are database backed deferred units of work that drive a large portion of our system's eventual consistency workflows. They were designed with a couple of key features in mind:

diff --git a/develop-docs/application/pii/index.mdx → develop-docs/backend/pii/index.mdx b/develop-docs/application/pii/index.mdx → develop-docs/backend/pii/index.mdx
@@ -1,7 +1,7 @@
 ---
 title: PII and Data Scrubbing
 description: This document describes a configuration format that we would like to hide from the user eventually. The only reason this page still exists is, because currently Relay accepts this format in alternative to regular data scrubbing settings.
-sidebar_order: 40
+sidebar_order: 170
 ---
 
 The following document explores the syntax and semantics of the configuration
@@ -25,7 +25,7 @@ It reads as "replace all IP addresses in all strings", or "apply `@ip:replace`
 to all `$string` fields".
 
 `@ip:replace` is called a rule, and `$string` is a <Link
-to="/pii/selectors/">selector</Link>.
+to="/backend/pii/selectors/">selector</Link>.
 
 ## Built-in Rules
 
@@ -50,10 +50,10 @@ The following rules exist by default:
 
 Rules generally consist of two parts:
 
-- _Rule types_ describe what to match. See <Link to="/pii/types/">PII Rule
+- _Rule types_ describe what to match. See <Link to="/backend/pii/types/">PII Rule
   Types</Link> for an exhaustive list.
 - _Rule redaction methods_ describe what to do with the match. See <Link
-  to="/pii/methods/">PII Redaction Methods</Link> for a list.
+  to="/backend/pii/methods/">PII Redaction Methods</Link> for a list.
 
 Each page comes with examples. Try those examples out by pasting them into the
 "PII config" column of [Piinguin] and clicking on fields to get suggestions.

diff --git a/develop-docs/application/pii/methods.mdx → develop-docs/backend/pii/methods.mdx b/develop-docs/application/pii/methods.mdx → develop-docs/backend/pii/methods.mdx
diff --git a/develop-docs/application/pii/selectors.mdx → develop-docs/backend/pii/selectors.mdx b/develop-docs/application/pii/selectors.mdx → develop-docs/backend/pii/selectors.mdx
diff --git a/develop-docs/application/pii/types.mdx → develop-docs/backend/pii/types.mdx b/develop-docs/application/pii/types.mdx → develop-docs/backend/pii/types.mdx
diff --git a/...-docs/development/python-dependencies.mdx → develop-docs/backend/python-dependencies.mdx b/...-docs/development/python-dependencies.mdx → develop-docs/backend/python-dependencies.mdx
@@ -1,6 +1,6 @@
 ---
 title: Python Dependencies
-sidebar_order: 9000
+sidebar_order: 20
 ---
 
 Unlike our frontend JavaScript story, where we're generally very happy pulling in dependencies, we're much more conservative on

diff --git a/develop-docs/services/queue.mdx → develop-docs/backend/queue.mdx b/develop-docs/services/queue.mdx → develop-docs/backend/queue.mdx
@@ -1,5 +1,6 @@
 ---
 title: Asynchronous Workers
+sidebar_order: 100
 ---
 
 Sentry comes with a built-in queue to process tasks in a more asynchronous fashion. For example when an event comes in instead of writing it to the database immediately, it sends a job to the queue so that the request can be returned right away, and the background workers handle actually saving that data.

diff --git a/develop-docs/services/quotas.mdx → develop-docs/backend/quotas.mdx b/develop-docs/services/quotas.mdx → develop-docs/backend/quotas.mdx
@@ -1,5 +1,6 @@
 ---
 title: Quotas
+sidebar_order: 150
 ---
 
 With the way Sentry works you may find yourself in a situation where you’ll see too much inbound traffic without a good way to drop excess messages. There’s a few solutions to this, and you’ll likely want to employ them all if you are faced with this problem.

diff --git a/...lication/transaction-clustering/index.mdx → .../backend/transaction-clustering/index.mdx b/...lication/transaction-clustering/index.mdx → .../backend/transaction-clustering/index.mdx
@@ -6,8 +6,8 @@ sidebar_order: 60
 Sentry attempts to scrub high-cardinality identifiers from URL transactions
 to aggregate performance data and provide more valuable insights.
 
-In terms of user experience, this feature plays a similar role as [Issue Grouping](/grouping/).
-In terms of technical implementation, it is similar to [Data Scrubbing](/pii/).
+In terms of user experience, this feature plays a similar role as [Issue Grouping](/backend/grouping/).
+In terms of technical implementation, it is similar to [Data Scrubbing](/backend/pii/).
 
 ## The Problem
 

diff --git a/...ication/transaction-clustering/merged.png → ...backend/transaction-clustering/merged.png b/...ication/transaction-clustering/merged.png → ...backend/transaction-clustering/merged.png
diff --git a/...lustering/transaction-clustering-arch.png → ...lustering/transaction-clustering-arch.png b/...lustering/transaction-clustering-arch.png → ...lustering/transaction-clustering-arch.png
diff --git a/...lustering/transaction-clustering-arch.svg → ...lustering/transaction-clustering-arch.svg b/...lustering/transaction-clustering-arch.svg → ...lustering/transaction-clustering-arch.svg
diff --git a/...plication/transaction-clustering/tree.png → ...s/backend/transaction-clustering/tree.png b/...plication/transaction-clustering/tree.png → ...s/backend/transaction-clustering/tree.png
diff --git a/...ransaction-clustering/unparameterized.png → ...ransaction-clustering/unparameterized.png b/...ransaction-clustering/unparameterized.png → ...ransaction-clustering/unparameterized.png
diff --git a/develop-docs/application/translations.mdx → develop-docs/backend/translations.mdx b/develop-docs/application/translations.mdx → develop-docs/backend/translations.mdx
@@ -1,6 +1,6 @@
 ---
 title: Translations
-sidebar_order: 90
+sidebar_order: 180
 ---
 
 We use [**Transifex**](https://www.transifex.com/getsentry/sentry) to translate Sentry.

diff --git a/develop-docs/services/tsdb.mdx → develop-docs/backend/tsdb.mdx b/develop-docs/services/tsdb.mdx → develop-docs/backend/tsdb.mdx
@@ -1,5 +1,6 @@
 ---
 title: Time-series Storage
+sidebar_order: 160
 ---
 
 Sentry provides a service to store time-series data. Primarily this is used to display aggregate information for events and projects, as well as calculating (in real-time) the rates of events.

diff --git a/develop-docs/development/analytics.mdx b/develop-docs/development/analytics.mdx
@@ -1,7 +1,7 @@
 ---
 title: Analytics
 description: This guide steps you through instrumenting your code with Sentry's 3rd-party analytics infrastructure.
-sidebar_order: 9000
+sidebar_order: 100
 ---
 
 
@@ -102,7 +102,7 @@ analytics.record(
 
 Run the tests that touch the endpoint to ensure everything is Gucci.
 
-### Step 3: 
+### Step 3:
 By default, a new event type is aggregated and sent to Amplitude as long as there is a user_id sent along with the event. If you would like to send events unaggregated, refer to [our Amplitude aggregation docs](https://github.com/getsentry/etl/blob/master/documentation/amplitude_analytics.md)
 
 ## Route-Based Frontend Analytics
@@ -290,7 +290,7 @@ class ExampleComponent extends React.Component {
 
 ## Metrics
 
-Track aggregrate stats with [Metrics](/services/metrics/). For example, this can be used to track aggregate response codes for an endpoint.
+Track aggregrate stats with [Metrics](/backend/metrics/). For example, this can be used to track aggregate response codes for an endpoint.
 
 Import the metrics library and use the `metrics.inc` function. The key needs to be unique.
 

diff --git a/develop-docs/development/code-review.mdx b/develop-docs/development/code-review.mdx
@@ -1,7 +1,7 @@
 ---
 title: Code Review
 description: Code review is mandatory at Sentry. This adds overhead to each change, but ensures that simple, often overlooked problems are more easily avoided.
-sidebar_order: 30
+sidebar_order: 20
 ---
 
 Code review helps build shared context and collective ownership. It is also an opportunity to collaborate with other teams. Finally, code review can identify several classes of problem before customers are exposed to them.

diff --git a/develop-docs/development/commit-messages.mdx b/develop-docs/development/commit-messages.mdx
@@ -1,7 +1,7 @@
 ---
 title: Commit Messages
 description: We have very precise rules over how our git commit messages can be formatted. This leads to more readable messages that are easy to follow when looking through the project history.
-sidebar_order: 20
+sidebar_order: 10
 ---
 
 ### General Rules

diff --git a/develop-docs/development/continuous-integration.mdx b/develop-docs/development/continuous-integration.mdx
@@ -1,7 +1,7 @@
 ---
 title: Continuous Integration
 description: Sentry uses a variety of continuous integration services to help ensure we don't accidentally break the application.
-sidebar_order: 35
+sidebar_order: 60
 ---
 
 ## Deployments

diff --git a/develop-docs/services/devservices.mdx → develop-docs/development/devservices.mdx b/develop-docs/services/devservices.mdx → develop-docs/development/devservices.mdx
@@ -1,5 +1,6 @@
 ---
 title: Service Manager (devservices)
+sidebar_order: 80
 ---
 
 Sentry provides an abstraction to Docker to run required services within development called `devservices`.

diff --git a/develop-docs/development/docs/index.mdx → develop-docs/development/documentation.mdx b/develop-docs/development/docs/index.mdx → develop-docs/development/documentation.mdx
@@ -1,7 +1,7 @@
 ---
 title: Documentation
 description: A part of every development project (especially Open Source projects) is documentation that explains how it works. Sentry is not any different.
-sidebar_order: 50
+sidebar_order: 30
 ---
 
 Because documentation is a big part of what makes Sentry work we’ve outlined some guidelines about how this documentation is structured and how to extend it.
@@ -44,4 +44,4 @@ Avoid adjacent code blocks without a paragraph of text in between. A code block
 
 ### Inclusive Language
 
-Sentry is a product used and developed by many people from different cultural backgrounds and we try to avoid language that has been identified as hurtful or insensitive. For detailed recommendations see <Link to="/development/inclusive-language/">Inclusive Language</Link>.
+Sentry is a product used and developed by many people from different cultural backgrounds and we try to avoid language that has been identified as hurtful or insensitive. For detailed recommendations see <Link to="/getting-started/inclusive-language/">Inclusive Language</Link>.