# Data-privacy & Security
Source: https://docs.sweetr.dev/about/data-privacy-and-security



Your data security and privacy come first. We follow strict security best practices to protect our servers and application.

## Data deletion

We understand the importance of data privacy. Upon uninstalling our GitHub app, we automatically hard delete all organizational data to ensure that no remnants are left behind. Your data is your own, and we respect your right to complete control over it.

## Source code handling

We do not store any of your repositories' source code. We only access the metadata required to provide our tools and features.

## GitHub permissions

Our GitHub app asks for permission for:

* Read: <Tooltip>members</Tooltip> and <Tooltip>metadata</Tooltip>.

* Read and write: <Tooltip>pull requests</Tooltip> and <Tooltip>commit status</Tooltip>.

These permissions are necessary to sync metadata from GitHub to our database and provide service to you.

## Minimal data storage

We save only the data needed to provide service to you. Less stored data means less risk.

## Trust and transparency

Our code is source-available. You're welcome to <a href="https://github.com/sweetr-dev/sweetr.dev">audit it yourself</a>. We believe trust is earned through transparency, not promises.

## Security inquiries

We're happy to answer any security questions from your organization.

<Info>Email [security@sweetr.dev](mailto:security@sweetr.dev) to inquire about our security practices.</Info>

## Report Vulnerabilities

Please report vulnerabilities directly to [security@sweetr.dev](mailto:security@sweetr.dev) - do not open an issue in our GitHub or post it anywhere else that is publicly accessible.


# Open Source
Source: https://docs.sweetr.dev/about/open-source



From code to community, Sweetr is made in the open. Our source code is public on GitHub, easy to audit, extend, and trust. Self-hosting is free, forever.

## License

Our projects are licensed under the <a href="https://fsl.software/">Functional Source License (FSL)</a>, the same license used by Sentry. This makes Sweetr **fair source**, not open source. The FSL allows use, modification, and distribution, but prevents commercial users from using our code to compete against us. After two years, the license automatically converts to Apache 2.0.

This gives our users freedom while keeping the project sustainable.

## Contributing

We welcome PRs from the community, whether it's bug fixes, new features, or documentation improvements.

Refer to our [Contribution Guidelines](https://github.com/sweetr-dev/sweetr.dev/blob/main/CONTRIBUTING.md) for more information.


# Principles
Source: https://docs.sweetr.dev/about/principles



Improvement is built on trust. Every design decision runs through the filter of "would a developer trust this?". These are the principles we build by.

<CardGroup>
  <Card title="Developer-first" icon="brackets-angle">
    Everything we build is designed with developers in mind. We don't surface
    data that can be weaponized. Every feature is considered to avoid enabling
    toxic practices, giving teams context to coach, not score.
  </Card>

  <Card title="Continuous Improvement" icon="seedling">
    Just like the developers we serve, we iterate constantly. We own our
    mistakes and acknowledge that, like everyone, we are prone to them. We
    improve based on user feedback, emerging trends, and our own convictions on
    what shapes a winning culture.
  </Card>

  <Card title="Clear by design" icon="crosshair">
    We surface only what matters. Our tools are simple, intuitive, and focused
    on what's actionable.
  </Card>

  <Card title="Community-oriented" icon="users">
    Our community is at the heart of everything we do. We actively seek out and
    incorporate community feedback. That's how we build a winning product.
  </Card>
</CardGroup>


# Roadmap
Source: https://docs.sweetr.dev/about/roadmap





# Authentication
Source: https://docs.sweetr.dev/api-reference/authentication

Authenticate requests to the Sweetr API using API keys.

All API requests must include a valid API key in the `Authorization` header using the Bearer scheme:

```bash theme={null}
Authorization: Bearer YOUR_API_KEY
```

## Generating API keys

API keys are scoped to a workspace. To generate one:

1. Open the Sweetr dashboard.
2. Navigate to **Settings > Workspace**.
3. Scroll down to the **API** section.
4. Click **Regenerate** and copy the generated key.

<Warning>
  API keys are only displayed once at creation time. Store them securely, for
  example as a secret in your CI/CD provider.
</Warning>

## Security best practices

* **Never commit API keys** to source control.
* **Use CI/CD secrets** (e.g., GitHub Actions secrets, GitLab CI variables) to inject keys at runtime.


# Create Deployment
Source: https://docs.sweetr.dev/api-reference/deployments/create-deployment

POST /v1/deployments

Track a new deployment for an application. If the application doesn't exist, it will be created automatically.

The request is processed asynchronously. A `202 Accepted` response means the deployment has been queued for processing.

## Body

<ParamField type="string">
  Full name of the GitHub repository (e.g., `owner/repo-name`). Max 255
  characters.
</ParamField>

<ParamField type="string">
  Target environment name (e.g., `production`, `staging`). Created automatically
  if it doesn't exist. Max 255 characters.
</ParamField>

<ParamField type="string">
  Application name. Created automatically if it doesn't exist. Max 255
  characters.
</ParamField>

<ParamField type="string">
  Version identifier for this deployment (e.g., `v1.2.3`, `build-456`). Max 70
  characters.
</ParamField>

<ParamField type="string">
  The full Git commit SHA being deployed. Max 70 characters.
</ParamField>

<ParamField type="string">
  A short description of the deployment. Max 255 characters.
</ParamField>

<ParamField type="string">
  The person who triggered the deployment. Max 255 characters.
</ParamField>

<ParamField type="string">
  ISO 8601 datetime of when the deployment occurred. Defaults to the current
  time if not provided.
</ParamField>

<ParamField type="string">
  Subdirectory path within the repository for monorepo setups. Max 255
  characters.
</ParamField>

## Response

<ResponseField name="status" type="number">
  `202`: The deployment has been accepted and queued for processing.
</ResponseField>

## Error codes

| Status | Description                                                              |
| ------ | ------------------------------------------------------------------------ |
| `422`  | Validation failed. Check the request body for missing or invalid fields. |
| `401`  | Invalid or missing API key.                                              |
| `429`  | Rate limit exceeded. See [Rate Limits](/api-reference/rate-limit).       |

<RequestExample>
  ```bash cURL theme={null}
  curl -X POST https://api.sweetr.dev/v1/deployments \
    -H "Authorization: Bearer YOUR_API_KEY" \
    -H "Content-Type: application/json" \
    -d '{
      "repositoryFullName": "acme/backend",
      "environment": "production",
      "app": "backend-api",
      "version": "v1.4.2",
      "commitHash": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2",
      "description": "Release v1.4.2",
      "author": "jane-doe"
    }'
  ```

  ```bash GitHub Actions theme={null}
  - name: Track deployment
    run: |
      curl -X POST https://api.sweetr.dev/v1/deployments \
        -H "Authorization: Bearer ${{ secrets.SWEETR_API_KEY }}" \
        -H "Content-Type: application/json" \
        -d '{
          "repositoryFullName": "${{ github.repository }}",
          "environment": "production",
          "app": "my-app",
          "version": "${{ github.sha }}",
          "commitHash": "${{ github.sha }}"
        }'
  ```
</RequestExample>


# Introduction
Source: https://docs.sweetr.dev/api-reference/introduction

Integrate your CI/CD pipeline with Sweetr using the REST API.

The Sweetr API lets you programmatically send data to Sweetr from your CI/CD pipelines and external tools.

## Base URL

All API requests are made to:

```
https://api.sweetr.dev
```

## Available endpoints

<CardGroup>
  <Card title="POST /v1/deployments" icon="rocket" href="/api-reference/deployments/create-deployment">
    Track a new deployment for an application.
  </Card>
</CardGroup>

## Related

<CardGroup>
  <Card title="Authentication" icon="key" href="/api-reference/authentication" />

  <Card title="Rate Limits" icon="gauge" href="/api-reference/rate-limit" />
</CardGroup>


# Rate Limits
Source: https://docs.sweetr.dev/api-reference/rate-limit

Understand the rate limits applied to the Sweetr API.

All API endpoints are rate limited to **100 requests per minute**, scoped to your API key. Requests that exceed the limit receive a `429 Too Many Requests` response.

## Handling rate limits

If you hit a rate limit, wait before retrying. The recommended approach is exponential backoff: wait 1 second, then 2, then 4, and so on.


# Alerts
Source: https://docs.sweetr.dev/automations/alerts

Real-time alerts for Pull Requests needing attention.

<Tip>You must enable Slack integration in order to enable alerts.</Tip>

## Demo

<Frame>
  <img />
</Frame>

<br />

<Frame>
  <img />
</Frame>

Alerts are team scoped, and must be enabled individually for each team. Each
alert can be toggled on or off individually, and their Slack channels can be
customized independently.

## Enabling alerts

Navigate to **Teams > \[Your Team] > Alerts** to configure alerts. Each alert type can be toggled on or off, and you can set a specific Slack channel per alert.

## Alert Types

<Card title="Slow review" icon="code">
  Alert when an open Pull Request has been waiting for review for too long. You
  can configure the minimum idle time (1 to 168 hours) to trigger the alert.

  <br />

  <p>`Improves cycle time` `Improves time to approval`</p>
</Card>

<Card title="Slow merge" icon="git-merge">
  Alert when an approved Pull Request has been waiting for merge for too long.
  You can configure the minimum idle time (1 to 168 hours) to trigger the alert.

  <br />

  <p>`Improves cycle time` `Improves time to merge`</p>
</Card>

<Card title="Merged without approval" icon="x">
  Alert when a Pull Request is merged without approvals.

  <br />

  <p>`Improves failure rate`</p>
</Card>

<Card title="(Coming Soon) Hot Pull Request" icon="flame">
  Alert when a Pull Request has a lot of comments or back-and-forth.
</Card>

<Card title="(Coming Soon) Too many unreleased changes" icon="rocket">
  Alert when many merged Pull Requests are pending release.
</Card>

<CtaGetStarted />


# Digests
Source: https://docs.sweetr.dev/automations/digests

Scheduled Slack digests to keep teams informed and aligned.

<Tip>You must enable Slack integration in order to enable digests.</Tip>

## Demo

<Frame>
  <img />
</Frame>

Digests can be sent monthly, weekly, or daily. Digests are team scoped, and must be enabled individually for each team.

## Metrics Digest

<Frame>
  <img />
</Frame>

The metrics digest includes a summary of metrics found in [Pull Request Flow](/metrics-and-insights/pr-flow/intro) and [Code Review Efficiency](/metrics-and-insights/code-review-efficiency/intro).

* Average Pull Request Size
* Average Cycle Time
  * Time to First Review
  * Time to Approve
  * Time to Merge

Enabling this digest helps teams understand their flow and areas for improvement. It removes the hurdle of having to manually check the metrics in the Sweetr dashboard.

## Work in Progress Digest

<Frame>
  <img />
</Frame>

The work in progress digest includes a summary of all the team's open Pull Requests found in [Work in Progress](/metrics-and-insights/wip).

Enabling this digest helps team alignment, by bringing visibility to any PRs that may need attention.

<CtaGetStarted />


# Incident Detection
Source: https://docs.sweetr.dev/automations/incident-detection

Automatically create incident records from rollbacks, hotfixes and reverts.

## How it works

Incident Detection automatically creates incidents when it detects problematic deployments. Incident Detection is enabled and pre-configured by default for every workspace. You can disable or customize the detection rules as needed.

### Rollback detection

Detects when a deployment reverts to a previously deployed version. Sweetr compares the commit history between deployments to identify rollbacks automatically.

| Incident field       | Value                                                           |
| -------------------- | --------------------------------------------------------------- |
| **Cause deployment** | The first deployment after the version that was rolled back to. |
| **Fix deployment**   | The rollback deployment itself.                                 |
| **Detected at**      | The time of the rollback deployment.                            |

For example, given deployment versions `A → B → C → D -> B²`:

* **Cause deployment**: `C` (the first deployment after `B`, where the problem was introduced)
* **Fix deployment**: `B²` (the rollback deployment itself)

### Hotfix detection

Detects incidents based on patterns in pull request titles, branch names, or labels. Configure regular expressions to match your team's conventions.

| Pattern            | Description                                              |
| ------------------ | -------------------------------------------------------- |
| **PR title regex** | Match pull request titles (e.g., `hotfix`, `emergency`). |
| **Branch regex**   | Match branch names (e.g., `^hotfix/.+`).                 |
| **PR label regex** | Match pull request labels.                               |

| Incident field       | Value                                                    |
| -------------------- | -------------------------------------------------------- |
| **Cause deployment** | The deployment immediately before the hotfix deployment. |
| **Fix deployment**   | The deployment containing the hotfix pull request.       |
| **Detected at**      | The time of the hotfix deployment.                       |

### Revert detection

Detects when a pull request is a revert of a previous change.

| Incident field       | Value                                                                   |
| -------------------- | ----------------------------------------------------------------------- |
| **Cause deployment** | The deployment that contained the original (now-reverted) pull request. |
| **Fix deployment**   | The deployment containing the revert pull request.                      |
| **Detected at**      | The time of the revert deployment.                                      |

## Benefits

<Card title="Improves data accuracy" icon="database">
  More accurate failure rate on your DORA metrics. Remove manual work from
  incident reporting.
</Card>

## Related

<CardGroup>
  <Card title="DORA Metrics" icon="chart-line" href="/metrics-and-insights/dora" />

  <Card title="Incidents" icon="flame" href="/platform/incidents" />

  <Card title="Deployments" icon="rocket" href="/platform/deployments" />
</CardGroup>

<CtaGetStarted />


# PR Size Labeler
Source: https://docs.sweetr.dev/automations/pr-size-labeler

Automatically label a Pull Request with its size.

## Demo

<Frame>
  <img />
</Frame>

## How it works

When enabled, Sweetr will automatically add a label indicating the size of the changes on every new Pull Request in GitHub. You can customize the labels and their colors.

Customize how PR size is calculated in your workspace settings.

## Benefits

<Card title="Improves cycle time" icon="clock">
  Encourage faster reviews on smaller PRs.
</Card>

<Card title="Improves failure rate" icon="bug">
  Mitigate reviewer fatigue with smaller PRs.
</Card>

## Default labels

<PrSize label="< 20 lines changed." />

<PrSize label="20~100 lines changed." />

<PrSize label="100~250 lines changed." />

<PrSize label="250~500 lines changed." />

<PrSize label="> 500 lines changed." />


# PR Title Requirements
Source: https://docs.sweetr.dev/automations/pr-title-check

Enforce PR title standards across your organization.

## Demo

<Frame>
  <img />
</Frame>

## How it works

Enable this automation in **Automations > PR Title Check** by defining a regular expression to validate Pull Request titles across your organization. When a PR is opened or updated, Sweetr posts a commit status check (`[Sweetr] PR Title Check`) with a **success** or **error** state.

By default the check is non-blocking. To make it required, add <a href="https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging">branch protection rules</a> in your repository that require the `[Sweetr] PR Title Check` status to pass before merging.

## Benefits

<Card title="Improves compliance" icon="gavel">
  Standardize Pull Request titles across the organization.
</Card>

## Popular Patterns

<CodeGroup>
  ```js [KEY-100] Foo theme={null}
  ^\[([A-Za-z]+-\d+)\]\s+.+$
  ```

  ```js feat: Foo theme={null}
  ^(feat|fix|chore|refactor|docs|test):\s+.+$
  ```

  ```js [KEY-100] feat: Foo theme={null}
  ^\[([A-Za-z]+-\d+)\]\s+(feat|fix|chore|refactor|docs|test):\s+.+$
  ```
</CodeGroup>


# Cloud
Source: https://docs.sweetr.dev/get-started/cloud



Our cloud solution is the fastest and easiest way to get started.

<Steps>
  <Step title="Login">
    To get started, simply <a href="https://app.sweetr.dev/">login with your GitHub account</a>.
  </Step>

  <Step title="Your first workspace">
    You'll be prompted to install our GitHub app.

    <Frame>
      <img />
    </Frame>
  </Step>

  <Step title="Review the permissions">
    Our GitHub app asks for permission for:

    * Read: <Tooltip>members</Tooltip> and <Tooltip>metadata</Tooltip>.

    * Read and write: <Tooltip>pull requests</Tooltip> and <Tooltip>commit status</Tooltip>.

    These permissions are necessary to sync metadata from GitHub to our database and provide service to you.

    <Note>We'll never store any of your repositories' code in our servers.</Note>

    You're more than welcome to audit our <a href="https://github.com/sweetr-dev/sweetr.dev">source code</a> to see exactly how the data is used. You can also <a href="https://github.com/sweetr-dev/sweetr.dev/issues">reach out</a> if you have any questions.
  </Step>

  <Step title="Choose where to install">
    We'll create a workspace for the organization or personal account where you choose the GitHub app to be installed.
  </Step>

  <Step title="The data sync starts">
    After installing the app, our app will start syncing metadata from your GitHub account. This process might take from a few minutes to several hours, depending on how much data your account has.
  </Step>

  <Step title="Complete onboarding">
    Once the sync starts, follow the [Onboarding Guide](/get-started/onboarding) to review what was set up and configure your workspace.
  </Step>
</Steps>


# Intro
Source: https://docs.sweetr.dev/get-started/intro

Welcome to sweetr.dev, the open platform for Developer Productivity++.

**What problems does it solve?**\
PRs get stuck. Bottlenecks stay hidden. Decisions happen without signals. Sweetr gives your team the visibility and automations to uncover friction, improve delivery, and build a better developer experience.

Explore the feature sections to learn how each tool can help your team.

**Who is it for?**\
Engineering managers, team leads, directors, and developers of teams of all sizes.

## Get Started

<CardGroup>
  <Card title="Cloud" icon="cloud" href="/get-started/cloud" />

  <Card title="Self-host" icon="server" href="/get-started/self-host" />
</CardGroup>


# Onboarding
Source: https://docs.sweetr.dev/get-started/onboarding

What Sweetr sets up for you and what to do next.

After installing the Sweetr GitHub App, we run an initial sync that pulls in your organization's repositories, pull requests, code reviews, and teams. This guide walks you through what was set up automatically and what you should review.

## Setup Teams

Sweetr imported your GitHub teams and their members during the initial sync.

<Warning>
  **This is a one-time import.**

  If you change teams in GitHub later, those changes won't show up in Sweetr.

  You'll need to edit teams directly in Sweetr going forward.
</Warning>

### What to do

<Steps>
  <Step title="Review your teams">
    Check the [Teams](/platform/teams) page. Make sure the imported teams match
    your current org structure and remove any that are outdated.
  </Step>

  <Step title="Adjust membership">
    Add or remove members as needed. See [Teams](/platform/teams) for details on
    roles and management.
  </Step>

  <Step title="Explore team insights">
    Once your teams look right, you're free to explore team-scoped views like
    [Work Log](/metrics-and-insights/work-log) and [Work in
    Progress](/metrics-and-insights/wip).
  </Step>
</Steps>

## Setup DORA metrics

To calculate [DORA metrics](/metrics-and-insights/dora), Sweetr needs to know about your [applications](/platform/applications), [deployments](/platform/deployments), and [incidents](/platform/incidents).

<AccordionGroup>
  <Accordion title="Applications" icon="cube">
    Sweetr created an application for each of your repositories during the initial sync. An application is a deployable unit that connects a repository to its deployments and environments.

    <Warning>
      **Sweetr supports monorepos but can't detect them on initial sync.**

      If you have monorepos, split the auto-created application into separate
      applications and map each to a subdirectory. This way pull requests get
      linked to the right application.
    </Warning>
  </Accordion>

  <Accordion title="Deployments" icon="rocket">
    Every auto-created application is pre-configured to consider the merge of a Pull Request as a deployment, so you have DORA metrics from day one.

    This is often inaccurate as many companies deploy multiple PRs at once. You should switch to the [API Webhook](/platform/deployments#setting-up-deployments-for-dora-metrics) trigger for full data accuracy.

    <Tip>
      **Tip:** After creating applications, you can go to Settings > Workspace and click
      "Resync all historical data" to backfill deployments from previously merged PRs.
    </Tip>
  </Accordion>

  <Accordion title="Incidents" icon="flame">
    Incidents are production issues caused by a deployment. They feed into Change Failure Rate and Mean Time to Recovery.

    Sweetr has [Incident Detection](/automations/incident-detection) enabled by default. It creates incidents when it spots rollbacks, hotfixes, or reverts. You can also [create them manually](/platform/incidents).
  </Accordion>
</AccordionGroup>

### What to do

<Steps>
  <Step title="Review your applications">
    Go to [Applications](/platform/applications) and check the auto-created
    list. If you have monorepos, split them into separate applications per
    service.
  </Step>

  <Step title="Tweak incident detection (optional)">
    The [Incident Detection](/automations/incident-detection) automation is
    already running. If your team uses specific branch names or PR labels for
    hotfixes, customize the patterns there. Then check
    [Incidents](/platform/incidents) to make sure the auto-detected ones look
    right.
  </Step>

  <Step title="Check your DORA dashboard">
    Go to [DORA Metrics](/metrics-and-insights/dora) to see how your team is
    doing.
  </Step>
</Steps>

## Inviting teammates

Share the workspace URL with your team. Anyone in your GitHub organization will auto-join when they log in with their GitHub account.

<Tip>
  You can restrict login access to organization admins only in **Settings > Workspace > Authentication**.
</Tip>

<CtaGetStarted />


# Self-host
Source: https://docs.sweetr.dev/get-started/self-host



When you choose to self-host, the responsibility for updates, maintenance, and
merging future enhancements rests entirely with you.

<Tip>
  We highly recommend the <a href="/get-started/cloud">Cloud</a> version, unless
  you have hard requirements to manage your own infrastructure.
</Tip>

## Minimum System Requirements

| Resource | Minimum | Recommended |
| -------- | ------- | ----------- |
| CPU      | 2 vCPU  | 4 vCPU      |
| RAM      | 2 GB    | 4 GB        |
| Disk     | 20 GB   | 40 GB       |

**Software requirements:**

* Docker 24+ and Docker Compose v2+
* A domain with DNS A record pointing to your server
* Ports 80 and 443 open (for web traffic and TLS)

## Quick Start

The fastest way to get Sweetr running is with our deploy script. It will guide you through
the setup, including creating a GitHub App with the correct permissions.

```bash theme={null}
curl -fsSL https://raw.githubusercontent.com/sweetr-dev/sweetr.dev/main/bin/deploy | bash
```

The script will:

1. Check that Docker and Docker Compose are installed
2. Ask for your domain and GitHub organization handle
3. Generate a pre-filled URL to create a GitHub App with all required permissions
4. Collect your GitHub App credentials
5. Optionally configure Slack integration
6. Generate `docker-compose.yml` and `.env` files
7. Start the stack

To install a specific version, set the `SWEETR_TAG` environment variable:

```bash theme={null}
curl -fsSL https://raw.githubusercontent.com/sweetr-dev/sweetr.dev/1.2.0/bin/deploy | SWEETR_TAG=1.2.0 bash
```

## Manual Setup

If you prefer to set things up manually, follow the steps below.

### Prerequisites

<Steps>
  <Step title="Create a GitHub Application">
    You'll need to <a href="https://docs.github.com/en/apps/creating-github-apps/registering-a-github-app/registering-a-github-app">create a GitHub application</a>.

    Use our pre-filled link to speed this up — replace `YOUR_DOMAIN` with your actual domain after opening it.

    <GitHubAppButton />

    After opening the link, you must also:

    * Uncheck **"Expire user authorization tokens"**
    * Generate and set a **Webhook Secret**
    * Submit the form, then **generate a Client Secret**
    * **Generate a Private Key** (this downloads a `.pem` file)

    <Tip>
      Create the app under your **organization** account (not your personal account) so it can be installed on the organization directly. Use `https://github.com/organizations/YOUR_ORG/settings/apps/new` as the base URL.
    </Tip>

    <Accordion title="Manual setup (without pre-filled link)">
      <Tabs>
        <Tab title="General">
          * Generate a Client Secret
          * Callback URL: `https://your-domain.com/github/callback`
          * Uncheck "Expire user authorization tokens"
          * Check "Request user authorization (OAuth) during installation"
          * Webhook
            * Check "Active"
            * Webhook URL: `https://your-domain.com/api/github/webhook`
            * Generate and set a Webhook Secret
          * SSL verification
            * Check "Enable SSL verification"
          * Generate a Private Key
        </Tab>

        <Tab title="Permissions & events">
          #### Repository permissions

          * Metadata: Read-only
          * Pull requests: Read and Write
          * Commit Statuses: Read and Write

          #### Organization permissions

          * Members: Read-only

          #### Account permissions

          * Email addresses: Read-only

          #### Subscribe to events

          * Installation target
          * Organization
          * Public
          * Pull request
          * Pull request review
          * Repository
        </Tab>
      </Tabs>
    </Accordion>
  </Step>

  <Step title="Create a Slack App (Optional)">
    Create a Slack app at [https://api.slack.com/apps/new](https://api.slack.com/apps/new):

    <Tabs>
      <Tab title="OAuth & Permissions">
        * Create a Redirect URL: `https://your-domain.com/settings/integrations/slack`
        * Add the following Bot Token Scopes:
          * `app_mentions:read`
          * `channels:join`
          * `channels:read`
          * `chat:write`
          * `groups:read`
          * `im:read`
          * `im:write`
          * `mpim:read`
          * `reactions:read`
          * `users.profile:read`
          * `users:read`
          * `users:read.email`
      </Tab>

      <Tab title="Event Subscriptions">
        * Set "Enable Events" to ON
        * Change the "Request URL" to `https://your-domain.com/api/slack/webhook`
      </Tab>
    </Tabs>
  </Step>

  <Step title="Create a Caddyfile">
    Create a `Caddyfile` for the reverse proxy. Caddy automatically provisions and renews
    HTTPS certificates via Let's Encrypt.

    ```
    your-domain.com {
        @api path /api /api/*
        handle @api {
            uri strip_prefix /api
            reverse_proxy api:8000
        }
        handle {
            reverse_proxy web:80
        }
    }
    ```

    <Note>
      A public domain is required — GitHub cannot deliver webhooks to `localhost`. For local development, use a tunnel like [Cloudflare Tunnel](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/) or [ngrok](https://ngrok.com/) and use the tunnel URL as your domain.
    </Note>
  </Step>

  <Step title="Create docker-compose.yml">
    Create a `docker-compose.yml` file:

    ```yaml theme={null}
    services:
      caddy:
        image: caddy:2
        container_name: sweetr-caddy
        ports:
          - "80:80"
          - "443:443"
          - "443:443/udp"
        volumes:
          - ./Caddyfile:/etc/caddy/Caddyfile:ro
          - sweetr-caddy-data:/data
          - sweetr-caddy-config:/config
        restart: unless-stopped
        networks:
          - sweetr
        depends_on:
          - api
          - web

      api:
        image: sweetr/api:latest
        container_name: sweetr-api
        env_file: .env
        environment:
          - NODE_ENV=production
          - APP_ENV=production
          - APP_MODE=self-hosted
          - USE_SELF_SIGNED_SSL=false
        restart: unless-stopped
        networks:
          - sweetr
        depends_on:
          postgres:
            condition: service_healthy
          valkey:
            condition: service_healthy

      web:
        image: sweetr/web:latest
        container_name: sweetr-web
        environment:
          - API_ENDPOINT=${API_ENDPOINT}
          - AUTH_COOKIE_DOMAIN=${AUTH_COOKIE_DOMAIN}
          - GITHUB_APP=${GITHUB_APP}
          - SENTRY_DSN=${SENTRY_DSN:-}
          - APP_ENV=${APP_ENV:-production}
        restart: unless-stopped
        networks:
          - sweetr
        depends_on:
          - api

      postgres:
        image: postgres:16
        container_name: sweetr-postgres
        env_file: .env
        volumes:
          - sweetr-db:/var/lib/postgresql/data
        restart: unless-stopped
        networks:
          - sweetr
        healthcheck:
          test: ["CMD-SHELL", "pg_isready -U postgres"]
          interval: 10s
          timeout: 5s
          retries: 5

      valkey:
        image: valkey/valkey:8-alpine
        container_name: sweetr-valkey
        volumes:
          - sweetr-valkey:/data
        restart: unless-stopped
        networks:
          - sweetr
        healthcheck:
          test: ["CMD-SHELL", "valkey-cli ping"]
          interval: 10s
          timeout: 5s
          retries: 5

    volumes:
      sweetr-db:
      sweetr-valkey:
      sweetr-caddy-data:
      sweetr-caddy-config:

    networks:
      sweetr:
        driver: bridge
    ```
  </Step>

  <Step title="Configure environment variables">
    Create a `.env` file. See the [Environment Variables Reference](#environment-variables-reference) below for all available options.

    ```bash theme={null}
    # Database
    POSTGRES_USER=postgres
    POSTGRES_PASSWORD=<generate-a-secure-password>
    POSTGRES_DB=sweetr
    DATABASE_URL=postgres://postgres:<POSTGRES_PASSWORD>@postgres:5432/sweetr

    # API
    PORT=8000
    FRONTEND_URL=https://your-domain.com
    JWT_SECRET=<generate-a-secure-random-string>
    REDIS_CONNECTION_STRING=redis://valkey:6379

    # GitHub App
    GITHUB_APP_ID=<your-app-id>
    GITHUB_CLIENT_ID=<your-client-id>
    GITHUB_CLIENT_SECRET=<your-client-secret>
    GITHUB_APP_HANDLE=<your-app-slug>
    # Private key: replace newlines with \n and wrap in double quotes
    GITHUB_APP_PRIVATE_KEY="-----BEGIN RSA PRIVATE KEY-----\nMIIE...\n-----END RSA PRIVATE KEY-----\n"
    GITHUB_WEBHOOK_SECRET=<your-webhook-secret>

    # Web
    API_ENDPOINT=https://your-domain.com/api
    AUTH_COOKIE_DOMAIN=your-domain.com
    GITHUB_APP=<your-app-slug>

    # Slack (optional)
    SLACK_CLIENT_ID=
    SLACK_CLIENT_SECRET=
    SLACK_WEBHOOK_SECRET=
    ```
  </Step>

  <Step title="Start the stack">
    ```bash theme={null}
    docker compose up -d
    ```

    The API container will automatically run database migrations on startup.
  </Step>

  <Step title="Complete onboarding">
    After logging in, the initial data sync will begin. Follow the [Onboarding Guide](/get-started/onboarding) to review what was set up and configure your workspace.
  </Step>
</Steps>

## Environment Variables Reference

### API (`sweetr/api`)

| Variable                                          | Required | Default            | Description                                |
| ------------------------------------------------- | -------- | ------------------ | ------------------------------------------ |
| `DATABASE_URL`                                    | Yes      | —                  | PostgreSQL connection string               |
| `REDIS_CONNECTION_STRING`                         | Yes      | —                  | Redis/Valkey connection string             |
| `JWT_SECRET`                                      | Yes      | —                  | Secret for signing JWT tokens              |
| `FRONTEND_URL`                                    | Yes      | —                  | URL of the web application                 |
| `PORT`                                            | No       | `3000`             | API server port                            |
| `GITHUB_APP_ID`                                   | Yes      | —                  | GitHub App ID                              |
| `GITHUB_CLIENT_ID`                                | Yes      | —                  | GitHub OAuth Client ID                     |
| `GITHUB_CLIENT_SECRET`                            | Yes      | —                  | GitHub OAuth Client Secret                 |
| `GITHUB_APP_HANDLE`                               | Yes      | —                  | GitHub App slug (from the app URL)         |
| `GITHUB_APP_PRIVATE_KEY`                          | Yes      | —                  | GitHub App private key (PEM format)        |
| `GITHUB_WEBHOOK_SECRET`                           | Yes      | —                  | Secret for verifying GitHub webhooks       |
| `GITHUB_OAUTH_REDIRECT_PATH`                      | No       | `/github/callback` | OAuth redirect path                        |
| `APP_MODE`                                        | No       | `self-hosted`      | `self-hosted` or `saas`                    |
| `NODE_ENV`                                        | No       | `production`       | `development` or `production`              |
| `APP_ENV`                                         | No       | `production`       | `development`, `staging`, or `production`  |
| `LOG_LEVEL`                                       | No       | `info`             | `debug`, `info`, `warn`, or `error`        |
| `USE_SELF_SIGNED_SSL`                             | No       | `false`            | Use self-signed SSL certificates           |
| `BULLMQ_ENABLED`                                  | No       | `true`             | Enable background job processing           |
| `SLACK_CLIENT_ID`                                 | No       | `""`               | Slack Client ID                            |
| `SLACK_CLIENT_SECRET`                             | No       | `""`               | Slack Client Secret                        |
| `SLACK_WEBHOOK_SECRET`                            | No       | `""`               | Slack webhook verification secret          |
| `STRIPE_API_KEY`                                  | No       | `""`               | Stripe API key (cloud billing only)        |
| `STRIPE_WEBHOOK_SECRET`                           | No       | `""`               | Stripe webhook secret (cloud billing only) |
| `SENTRY_DSN`                                      | No       | `""`               | Sentry DSN for error tracking              |
| `LOG_DRAIN`                                       | No       | `console`          | `console` or `logtail`                     |
| `LOGTAIL_TOKEN`                                   | No       | `""`               | LogTail source token                       |
| `EMAIL_ENABLED`                                   | No       | `false`            | Enable transactional emails                |
| `RESEND_API_KEY`                                  | No       | `""`               | Resend API key for emails                  |
| `BULLBOARD_PATH`                                  | No       | `""`               | URL path to access BullBoard dashboard     |
| `BULLBOARD_USERNAME`                              | No       | `""`               | BullBoard login username                   |
| `BULLBOARD_PASSWORD`                              | No       | `""`               | BullBoard login password                   |
| `CRON_GITHUB_RETRY_FAILED_WEBHOOKS_EVERY_MINUTES` | No       | `30`               | Retry interval for failed webhooks         |

### Web (`sweetr/web`)

| Variable             | Required | Default      | Description                                                  |
| -------------------- | -------- | ------------ | ------------------------------------------------------------ |
| `API_ENDPOINT`       | Yes      | —            | Full URL to the API (e.g., `https://sweetr.example.com/api`) |
| `AUTH_COOKIE_DOMAIN` | Yes      | —            | Domain for auth cookies (e.g., `example.com`)                |
| `GITHUB_APP`         | Yes      | —            | GitHub App slug (same as `GITHUB_APP_HANDLE`)                |
| `SENTRY_DSN`         | No       | `""`         | Sentry DSN for frontend error tracking                       |
| `APP_ENV`            | No       | `production` | Environment name for Sentry                                  |

## Upgrading

To upgrade to a new version:

```bash theme={null}
cd sweetr
docker compose pull
docker compose up -d
```

Database migrations run automatically on API container startup.

To pin a specific version instead of `latest`, edit the image tags in `docker-compose.yml`:

```yaml theme={null}
services:
  api:
    image: sweetr/api:1.2.0
  web:
    image: sweetr/web:1.2.0
```

## Monitoring (Optional)

### Sentry

Add to your API `.env`:

```bash theme={null}
SENTRY_DSN=https://your-sentry-dsn
```

For frontend error tracking, also add to your `.env`:

```bash theme={null}
SENTRY_DSN=https://your-frontend-sentry-dsn
```

The web container reads this as the `SENTRY_DSN` environment variable.

### LogTail

```bash theme={null}
LOG_DRAIN=logtail
LOGTAIL_TOKEN=your-logtail-token
```

### BullBoard (Job Queue Dashboard)

To enable the BullBoard dashboard for monitoring background jobs:

```bash theme={null}
BULLBOARD_PATH=/bullboard
BULLBOARD_USERNAME=admin
BULLBOARD_PASSWORD=<secure-password>
```

Access it at `https://your-domain.com/api/bullboard`.

## Troubleshooting

### API fails to start

Check the container logs:

```bash theme={null}
docker compose logs api
```

Common causes:

* **Database connection failed**: Ensure Postgres is healthy with `docker compose ps`. The API waits for migrations to run on startup.
* **Missing environment variables**: The API will log which required variables are missing.
* **Redis connection failed**: Ensure Valkey is healthy. Check that `REDIS_CONNECTION_STRING` uses the Docker service name (e.g., `redis://valkey:6379`).

### Web app shows blank page

Check the browser console for errors. Common causes:

* **`API_ENDPOINT` is wrong**: Make sure it's the full URL reachable from the browser (not an internal Docker hostname).
* **CORS errors**: Ensure `FRONTEND_URL` on the API matches the URL you're accessing the web app from.

### Database migration errors

If migrations fail on startup, check the API logs. You may need to connect to Postgres directly:

```bash theme={null}
docker compose exec postgres psql -U postgres -d sweetr
```

### Port conflicts

If port 80 or 443 is already in use, either stop the conflicting service or change the Caddy port mappings in `docker-compose.yml`:

```yaml theme={null}
caddy:
  ports:
    - "8080:8080" # Change host port
```

Then update your `Caddyfile` to match (e.g., `:8080 {`) and adjust `FRONTEND_URL` and `API_ENDPOINT` in `.env` accordingly.


# Intro
Source: https://docs.sweetr.dev/metrics-and-insights/code-review-efficiency/intro

How your team reviews code — who's involved, how fast, and how deep.

<Frame>
  <img />
</Frame>

## How It Works

The **Code review efficiency** dashboard focuses on the review stage of the PR lifecycle. It answers three questions at once: *how fast* reviews happen, *how deep* they are, and *who* is doing them. All charts respect the same filters at the top of the page:

* **Date range** — the window of PRs and reviews to include.
* **Team** — filter by PR author's team membership. Multi-select.
* **Repository** — filter by repository. Multi-select.
* **Period** — group the time axis as daily, weekly, monthly, quarterly, or yearly.

Most charts are scoped to **merged PRs**. The **Review distribution** graph uses all code reviews in the range (merged or not).

## Explore

<CardGroup>
  <Card title="KPIs" href="/metrics-and-insights/code-review-efficiency/kpis" />

  <Card title="Review Speed" href="/metrics-and-insights/code-review-efficiency/review-speed" />

  <Card title="Team Overview" href="/metrics-and-insights/code-review-efficiency/team-overview" />

  <Card title="PR Size vs Comments" href="/metrics-and-insights/code-review-efficiency/pr-size-vs-comments" />

  <Card title="Review Distribution" href="/metrics-and-insights/code-review-efficiency/review-distribution" />
</CardGroup>

## Bad Practices

It's very important to know how this data should **not** be used.

* **Do not** evaluate review quality based on quantity.
* **Do not** stack rank developers by review count, speed, or comments.
* **Do not** obsess over a single KPI — drive review speed to zero and you'll lose the value of review itself. Strive for a good balance of quality and speed.

## Related

<CardGroup>
  <Card title="Pull Request Flow" href="/metrics-and-insights/pr-flow/intro" />

  <Card title="DORA Metrics" href="/metrics-and-insights/dora" />

  <Card title="Pull Requests" href="/platform/pull-requests" />

  <Card title="Code Reviews" href="/platform/code-reviews" />
</CardGroup>

<CtaGetStarted />


# KPIs
Source: https://docs.sweetr.dev/metrics-and-insights/code-review-efficiency/kpis

Time to first review, time to approval, comments per PR, and merges without approval.

Four headline numbers with a comparison to the previous window of the same length.

### Time to first review

Average elapsed time from a PR being ready for review to the first non-author review submission, for reviews that happened in the selected period.

* **Start ("ready"):** the earliest available among first reviewer requested, "marked ready for review," or PR creation. Draft PRs are not ready.
* **End:** first non-author, non-bot review submission.
* **Aggregation:** mean.
* **Direction:** lower is better.

### Time to approve

Average elapsed time from the first review on a PR to the first approval, for approvals that happened in the selected period.

* **Start:** first review submission.
* **End:** first approval.
* **Aggregation:** mean across PRs with both timestamps.
* **Direction:** lower is better.

### Avg comments per PR

Average number of comments on merged PRs in the period (issue and review thread activity on the PR).

* **Direction:** higher is better, within reason. Zero comments on non-trivial PRs is a red flag; triple-digit comment threads usually mean the PR is too big or the review process has scope creep.

### Merged without approval

Count of merged PRs that never received an approval in GitHub (as Sweetr sees it from your connected data).

* **Direction:** lower is better.
* **Caveat:** some teams intentionally allow self-merge for bots, hotfixes, or single-contributor repositories. Calibrate against what's expected, not zero.

Each KPI shows the absolute value, the percent change vs the previous period of the same length, and the previous value for context.

## See Also

<Card title="Review Speed" href="/metrics-and-insights/code-review-efficiency/review-speed" icon="chart-histogram" />


# PR Size vs Comments
Source: https://docs.sweetr.dev/metrics-and-insights/code-review-efficiency/pr-size-vs-comments

Lines changed vs review comment count per merged PR.

Scatter of **merged PRs** in the selected period, plotting **lines changed** (log scale) against **review comment count**. Each dot is one PR, colored by size bucket. Click any dot to open the PR on GitHub.

### Why it matters

A healthy review process scales attention with change size. This chart surfaces where that relationship breaks.

### What to look for

* **Bottom-right outliers** (big PR, no comments) — review blind spots worth auditing. Risky changes went in without scrutiny.
* **Top-left outliers** (tiny PR, many comments) — contentious changes, unclear conventions, or new contributors who need support.
* **Clean diagonal** — attention scales with size. That's the signal you want.

### How the chart is built

* **Horizontal axis:** total lines added plus deleted on the PR.
* **Vertical axis:** comment count on the PR (threads and discussion Sweetr attributes to that PR).
* **Color:** the same size bucket you use elsewhere (Tiny through Huge), based on lines changed and your workspace thresholds.
* To keep the chart responsive, it includes at most the **2,000 most recently merged** PRs in the selected range.

## See Also

<Card title="PR Size Distribution (PR Flow)" href="/metrics-and-insights/pr-flow/size-distribution" icon="layout-grid" />


# Review Distribution
Source: https://docs.sweetr.dev/metrics-and-insights/code-review-efficiency/review-distribution

Graph of who reviews whom, weighted by review count.

Graph of **who reviews whom** across the selected period. Nodes are people (reviewers and authors); edges represent review relationships, weighted by the number of reviews exchanged.

Node size is relative to an even split: **total reviews ÷ number of reviewers**. A node bigger than that baseline means that person is pulling more weight than their share.

Hover a node to see the full breakdown, including the split between reviews for **in-team** members vs **external** authors. Drag to pan, scroll to zoom.

A tabular summary below the graph lists each reviewer's share of total reviews.

### Why it matters

Review load tends to concentrate on a few seniors, which creates bottlenecks, burnout risk, and knowledge silos. A healthy graph is dense and roughly evenly sized; an unhealthy one has a few giant hubs and many loose ends.

### What to use it for

* Spot **review heroes** carrying the team and redistribute load.
* Detect **knowledge silos** — authors who only ever get reviewed by the same one or two people.
* Measure **cross-team review** by the in-team vs external split shown on hover.
* Validate whether your reviewer assignment strategy (CODEOWNERS, round-robin, manual) is actually producing the distribution you want.

### What good looks like

Each team is unique; only iteration finds the right balance.

In general, teams benefit from a somewhat even load of reviews per developer. Senior engineers will naturally do more. What matters is that **everyone contributes**, knowledge spreads, and no one person is a single point of failure.

### How to improve

* Visit this chart during retros.
* Talk about review ownership in 1:1s and performance conversations.
* Encourage new developers to review code early in onboarding — even if only to ask questions.
* Make sure the team feels safe giving feedback. Pair this chart with the [Pull requests](/platform/pull-requests) view to sanity-check review tone.

### How the chart is built

* **Lines between people** connect a reviewer to an author. Thickness reflects how many times that reviewer left a review on that author's PRs in the range.
* **In-team vs external** on the tooltip: Sweetr flags whether the author is on a team you share with the reviewer, or comes from outside that circle — useful for seeing cross-team load.
* **Node size** compares each person to a fair share of the total review work (same for everyone in the view). Bigger = more than their share of reviews; smaller = less.

## See Also

<Card title="Code Review Efficiency — Intro" href="/metrics-and-insights/code-review-efficiency/intro" icon="eye" />


# Review Speed
Source: https://docs.sweetr.dev/metrics-and-insights/code-review-efficiency/review-speed

Stacked time to first review and time to approval per period.

Breaks down review latency into two stacked bars per period, using **merged PRs** only.

* **Time to first review** — from PR marked ready for review to the first review submitted. Measures how long authors wait before someone picks their PR up.
* **Time to approval** — from first review to the approval that unblocks merge. Measures how long review conversations drag on.

Click a column to drill into the PRs merged in that period.

### Why it matters

Long turnaround kills flow: context gets stale, authors start new work, and rebases pile up. Splitting first review from approval tells you *where* the time goes:

* Thick **first review** → reviewers aren't picking PRs up.
* Thick **approval** → threads drag on, nitpicks, or too many rounds.

### What good looks like

Most small PRs should get a first review within hours. Time to approval varies with change complexity, but should trend down as review discipline improves.

### How to improve

* **For slow first review:** set a team SLA, simplify reviewer assignment (codeowners, round-robin), and enable [Alerts](/automations/alerts) for stuck reviews.
* **For slow approval:** move style to linters, discourage nitpicks, outline requirements in tickets, and encourage authors to review their own diff before requesting reviews.
* Keep PRs small. Review latency scales non-linearly with size.

### How the numbers are built

* **Time to first review** is averaged for each period. A PR is placed in the bucket that contains when the first review happened. The clock starts when the PR is **ready** (see below) and stops at the first human review (not the author, not bots).
* **Time to approval** is the average time from that first review until the first approval in the same bucket (by when the approval landed). If a PR never got a first review, it does not contribute here.
* **Business time:** weekends are excluded; only full weekdays count.

**When a PR counts as "ready"** matches the rest of Sweetr: the earliest of (1) first review request, (2) marked ready for review (drafts are not ready), or (3) opening the PR — using only what happened before the first review.

## See Also

<Card title="Code Review Efficiency — Intro" href="/metrics-and-insights/code-review-efficiency/intro" icon="eye" />


# Team Overview
Source: https://docs.sweetr.dev/metrics-and-insights/code-review-efficiency/team-overview

Avg time to first review, time to approval, and merges without approval by team.

Per-team roll-up of review performance, always including an **All teams** row for org-wide context.

* **Avg time to first review** — mean time from ready to first review.
* **Avg time to approval** — mean time from first review to approval.
* **Merged without approval** — count of merged PRs that never had an approval on GitHub in that window.

Table rows use who **authored** the PR to decide their team. The table is hidden if no team had any review activity in the period.

### How to use it

* Compare each team's review speed to the **All teams** baseline, not to each other.
* A team with many PRs **merged without approval** plus a low approval time is worth a closer look; that pattern often indicates rubber-stamping.
* Use it to pick the team for your next retro or coaching conversation.

## See Also

<Card title="Review Distribution" href="/metrics-and-insights/code-review-efficiency/review-distribution" icon="affiliate" />


# DORA Metrics
Source: https://docs.sweetr.dev/metrics-and-insights/dora

Measure software delivery performance with the four DORA metrics.

## Demo

<Frame>
  <img />
</Frame>

## How it works

DORA metrics are four key indicators of software delivery performance, developed by the [DORA research program](https://dora.dev). Sweetr calculates these metrics from your deployment and incident data.

All metrics support filtering by **team**, **application**, **environment**, and **date range**, and include a comparison against the previous period.

## Metrics

### Deployment Frequency

How often your team deploys to production. Higher frequency indicates smaller, more manageable releases.

* **Calculation:** Count of deployments in the selected period.
* **Chart:** Deployments over time with average per day.

### Lead Time for Changes

The time from first commit to production deployment. Lower lead time means faster delivery.

* **Calculation:** Time from first commit to deployment, averaged across all deployments.
* **Breakdown:**
  * **Coding time**: First commit to pull request creation.
  * **Time to first review**: PR creation to first review.
  * **Time to approve**: First review to approval.
  * **Time to merge**: Approval to merge.
  * **Time to deploy**: Merge to deployment.

### Change Failure Rate

The percentage of deployments that cause an incident. Lower rate indicates more stable releases.

* **Calculation:** `(Incidents caused by deployments / Total deployments) × 100`
* **Requires:** [Incidents](/platform/incidents) linked to deployments.

### Mean Time to Recovery (MTTR)

The average time to recover from an incident. Lower MTTR indicates faster incident response.

* **Calculation:** Average of `resolved at - detected at` across all resolved incidents.
* **Requires:** [Incidents](/platform/incidents) with detection and resolution timestamps.

## Benchmarks

The DORA research program publishes annual benchmarks that categorize teams into Elite, High, Medium, and Low performers. Use these to assess where your team stands and set realistic goals. See the <a href="https://dora.dev/guides/dora-metrics-four-keys/">official DORA guides</a> for the latest thresholds.

## Prerequisites

To get the most out of DORA metrics:

<Steps>
  <Step title="Set up applications">
    Create [applications](/platform/applications) and configure their deployment
    settings.
  </Step>

  <Step title="Track deployments">
    Send deployments via the
    [API](/api-reference/deployments/create-deployment), PR merges, or GitHub
    deployment events.
  </Step>

  <Step title="Track incidents">
    Create [incidents](/platform/incidents) manually or enable [Incident
    Detection](/automations/incident-detection) to automate it.
  </Step>
</Steps>

## Related

<CardGroup>
  <Card title="Deployments" icon="rocket" href="/platform/deployments" />

  <Card title="Applications" icon="cube" href="/platform/applications" />

  <Card title="Incidents" icon="flame" href="/platform/incidents" />

  <Card title="Incident Detection" icon="circle-dot" href="/automations/incident-detection" />
</CardGroup>

<CtaGetStarted />


# PR Cycle Time Breakdown
Source: https://docs.sweetr.dev/metrics-and-insights/pr-flow/cycle-time-breakdown

Mean cycle time split into coding, first review, approval, and merge.

Splits mean **cycle time** for **merged PRs** into its four sequential phases, stacked per period. The **white line** is total cycle time (sum of the four phases).

* **Coding** — first commit to PR marked ready for review.
* **First review** — ready for review to first review submitted.
* **Approval** — first review to the approval that unblocks merge.
* **Merge** — approval to merge (usually CI + merge queue).

Click a column to drill into the PRs merged in that period.

### Why it matters

Cycle time is the end-to-end "idea to shipped" clock, but the average alone hides where time actually goes. This breakdown tells you *which phase* to attack first: slow reviews, stale approvals, flaky CI, or authors sitting on branches.

### What good looks like

High-performing teams aim for a median cycle time **under 24 hours**, but what matters more is the shape of the breakdown. A healthy team's cycle time is dominated by **Coding**, with thin slivers for first review, approval, and merge. When review or merge phases grow, the team is waiting, not building.

### How to improve

Pick the thickest phase and attack it:

* **Coding dominates** — PRs may be too big, or authors are parking branches. See [PR size distribution](/metrics-and-insights/pr-flow/size-distribution).
* **First review dominates** — reviewers aren't picking PRs up. Shorten assignment rules, set a team SLA, or enable [Alerts](/automations/alerts) on stuck reviews.
* **Approval dominates** — review threads drag on. Cut nitpicks, move style to linters, and coach the team on trusting small changes.
* **Merge dominates** — flaky CI or a crowded merge queue. Stabilize CI and prioritize shipping what's ready over starting new work.

### How the timing works

* **Total cycle time** is end-to-end for each merged PR: from first commit to merge.
* The chart splits that time into **coding** (up to "ready" for review), **first review**, **approval**, and **merge** (e.g. CI, queue) using the same events you see in Git.
* In edge cases, those slices can overlap. Sweetr **normalizes** them so the four segments always add up to the same total cycle time, then **averages** that per period. The white line (total) always matches the sum of the four bands, so you can compare weeks fairly.

## See Also

<Card title="PR Size vs Cycle Time" href="/metrics-and-insights/pr-flow/size-vs-cycle-time" icon="chart-scatter" />


# Intro
Source: https://docs.sweetr.dev/metrics-and-insights/pr-flow/intro

How work moves through your team, from first commit to merge.

<Frame>
  <img />
</Frame>

## How It Works

The **Pull Request flow** dashboard visualizes how your team ships code: throughput, batch size, and where cycle time is spent. All charts respect the same filters at the top of the page:

* **Date range** — the window of PRs to include.
* **Team** — filter by PR author's team membership. Multi-select.
* **Repository** — filter by repository. Multi-select.
* **Period** — group the time axis as daily, weekly, monthly, quarterly, or yearly.

Unless noted otherwise, charts include **merged PRs** whose **merge** falls inside the selected date range.

## Explore

<CardGroup>
  <Card title="PR Throughput" href="/metrics-and-insights/pr-flow/throughput" />

  <Card title="PR Size Distribution" href="/metrics-and-insights/pr-flow/size-distribution" />

  <Card title="PR Cycle Time Breakdown" href="/metrics-and-insights/pr-flow/cycle-time-breakdown" />

  <Card title="PR Size vs Cycle Time" href="/metrics-and-insights/pr-flow/size-vs-cycle-time" />

  <Card title="Team Overview" href="/metrics-and-insights/pr-flow/team-overview" />
</CardGroup>

## Bad Practices

It's very important to know how this data should **not** be used.

* **Do not** stack rank developers or teams by throughput or cycle time.
* **Do not** optimize a single metric in isolation — faster merges with fewer reviews is not a win.
* **Do not** treat throughput as a productivity score; it ignores complexity, quality, and risk.

## Related

<CardGroup>
  <Card title="Code Review Efficiency" href="/metrics-and-insights/code-review-efficiency/intro" />

  <Card title="DORA Metrics" href="/metrics-and-insights/dora" />

  <Card title="Pull Requests" href="/platform/pull-requests" />

  <Card title="Work in Progress" href="/metrics-and-insights/wip" />
</CardGroup>

<CtaGetStarted />


# PR Size Distribution
Source: https://docs.sweetr.dev/metrics-and-insights/pr-flow/size-distribution

Merged PRs bucketed by size with average lines changed per period.

Per-period stacked bar of **merged PRs** bucketed by size (lines added + deleted). An overlaid **white line** tracks the average lines changed per PR on the right axis.

The bucket thresholds come from your workspace settings. Defaults:

<PrSize label="< 20 lines changed." />

<PrSize label="20~100 lines changed." />

<PrSize label="100~250 lines changed." />

<PrSize label="250~500 lines changed." />

<PrSize label="> 500 lines changed." />

Click a column to inspect the PRs merged in that period.

### Why it matters

Small PRs are easier to review, safer to ship, and faster to merge. When the distribution skews to Large/Huge, reviews get superficial, merge conflicts pile up, and cycle time balloons. This chart makes the team's "default PR size" visible so you can push culture toward smaller batches.

### What good looks like

Most merged PRs should sit in the **Tiny** and **Small** buckets. Large and Huge should be the exception and tied to clear structural work (big migrations, codegen), not regular feature development.

### How to improve

* Break tickets into vertical slices before coding starts.
* Try <a href="https://www.stacking.dev/">stacking</a> PRs for dependent changes instead of one megabranch.
* Separate refactors and moves from behavior changes. Ship the mechanical change, then the logic change.
* Keep CI fast and painless so the cost of shipping one more PR is low.

### How the chart is built

* Each merged PR is bucketed by **total lines added and deleted** using the size thresholds in your workspace settings (the same Tiny → Huge scale as elsewhere in Sweetr).
* The stacked bars show how many PRs fell in each size bucket in each time period.
* The white line is the **average total lines changed** for merged PRs in that same period.

## See Also

<Card title="PR Cycle Time Breakdown" href="/metrics-and-insights/pr-flow/cycle-time-breakdown" icon="git-compare" />


# PR Size vs Cycle Time
Source: https://docs.sweetr.dev/metrics-and-insights/pr-flow/size-vs-cycle-time

Scatter of cycle time and lines changed per merged PR.

Scatter of **merged PRs** in the selected period, plotting **cycle time** (x, log scale) against **lines changed** (y, log scale). Each dot is one PR, colored by size bucket. Limited to 2,000 most recently merged PRs for performance. Click any dot to open the PR on GitHub.

### Why it matters

PR size is the single biggest predictor of cycle time. This chart makes that relationship concrete for your team and surfaces outliers that don't follow it.

### What to look for

* **Top-right cluster** (big + slow) — confirms the "ship smaller PRs" argument with data.
* **Far-right outliers** (any size, multi-day cycle) — PRs that got stuck. Check whether in review, waiting on CI, or idle.
* **Bottom-right** (small PR, long cycle) — process friction unrelated to size: bad CI, review drought, or forgotten PRs.
* **Top-left** (big PR, fast cycle) — either a rubber-stamped review or well-prepared structural change.

## See Also

<Card title="PR Size Distribution" href="/metrics-and-insights/pr-flow/size-distribution" icon="layout-grid" />


# Team Overview
Source: https://docs.sweetr.dev/metrics-and-insights/pr-flow/team-overview

Median cycle time, merge count, and PR size by team.

A per-team roll-up table, always including an **All teams** row for org-wide context. Columns:

* **Median cycle time** — the middle value if you ordered every merged PR by total cycle time (half the PRs are faster, half are slower).
* **Merged PRs** — how many PRs from that team merged in the period.
* **Avg PR size** — average of total lines added and deleted for those PRs.
* **% large+ PRs** — share of merged PRs that Sweetr classifies as **Large** or **Huge** using your workspace size rules.

All columns sort. A PR counts toward a team by **its author's** team membership in your workspace.

### Why it matters

Averages across the whole org hide the team that's driving them. The breakdown lets you spot which team is bottlenecked, who's shipping big batches, and where a process change should land first.

### How to use it

* Benchmark teams against the **All teams** row, not against each other.
* Pair **median cycle time** with **% large+ PRs** to separate "slow because big" from "slow for other reasons."
* Use it to pick the team for your next retro or coaching conversation.

## See Also

<Card title="Pull Request Flow — Intro" href="/metrics-and-insights/pr-flow/intro" icon="activity" />


# PR Throughput
Source: https://docs.sweetr.dev/metrics-and-insights/pr-flow/throughput

Opened, merged, and closed PRs per time bucket.

Per-period counts of PR activity, with two bars side by side:

* **Opened** — PRs created in that period. Measures work started.
* **Merged / Closed** — stacked bar of PRs that exited the queue. Measures work shipped vs dropped.

Click a column to jump to the PRs opened, merged, or closed in that period.

### Why it matters

Throughput is the raw delivery rate. Compared against opens, it surfaces whether the team is keeping up with incoming work or building up WIP. A rising close rate (vs merge) can hint at abandoned branches or scope churn.

### Insights

* Are we shipping faster than we're opening new work, or falling behind?
* Are closed-without-merge PRs growing? That usually means scope churn or abandoned branches.
* Did a process change actually lift throughput, or just shift where the work sits?

### How the chart is built

* **Opened** counts PRs by **when they were created** in the selected range.
* **Merged** counts PRs by **when they were merged** in the range.
* **Closed (without merge)** counts PRs that were closed in the range but never merged.
* Time buckets (daily, weekly, etc.) always appear for the full date range you picked; a bucket with no activity shows as zero.

## See Also

<Card title="Pull Request Flow — Intro" href="/metrics-and-insights/pr-flow/intro" icon="activity" />


# Work In Progress
Source: https://docs.sweetr.dev/metrics-and-insights/wip

Real-time view of the team's open Pull Requests, grouped by status.

## Demo

<Frame>
  <img />
</Frame>

## How it works

The Work in Progress page provides a real-time view of all the team's open Pull Requests, grouped by their status into four columns:

* **Drafted** — PRs still in draft.
* **Pending Review** — Open PRs waiting for a review.
* **Changes Requested** — PRs where a reviewer requested changes.
* **Pending Merge** — Approved PRs waiting to be merged.

This is a focused view of the [Pull Requests](/platform/pull-requests) page, and can be used to get a quick overview of the team's work in progress.

## Use cases

* Run better daily meetings.
* Identify blocked PRs.
* Identify PRs with a lot of comments that might need attention.

## Use it with

<Card title="Slack Digest" icon="message" href="/automations/digests#work-in-progress-digest">
  Send daily snapshots of your team's Work In Progress to a channel in Slack.
</Card>

<CtaGetStarted />


# Work Log
Source: https://docs.sweetr.dev/metrics-and-insights/work-log

A weekly view of your team's pull requests and code reviews.

## Demo

<Frame>
  <img />
</Frame>

## How it works

A weekly view of your team's pull requests and code reviews. Each icon represents a PR or review, and grows in size with the change. Spot where work flows, where it piles up, and where it's stuck.

Contributions from each team member are organized by day and grouped into three categories:

* **Opened PRs** (green hexagons)
* **Merged PRs** (purple hexagons)
* **Code reviews** (speech bubble icons)

The size of each icon varies based on the PR size, giving a clear indication of the effort involved. Hovering over an icon provides additional details, including the PR title, repository name, number of comments, and size.

### Use it to

#### For leaders

* **Spot workload imbalance:** Quickly see if work is spread evenly or if someone is consistently overloaded.
* **Prepare for 1:1s:** Walk into conversations with concrete context on what happened that week, not just gut feelings.
* **Recognize effort, not just volume:** Fewer, larger icons mean someone tackled a big piece of work. Not every week needs a wall of dots.
* **Check in early:** A quiet week can mean someone is blocked. Use it as a signal to offer support, not to judge.

#### For individual contributors

* **Build your brag document:** Use the Work Log to highlight contributions during 1:1s or performance reviews.
* **Support promotion cases:** Provide concrete evidence of high-impact work and consistency over time.
* **Document growth:** See your progress over time and identify areas where you've improved or taken on more complex tasks.

### Bad practices

It's very important to know how this data should not be used. The Work Log is **not intended to measure individual productivity.** It only reflects activity related to PRs and code reviews. It doesn't account for essential work outside of code contributions, like planning, meetings, research, or documentation.

Use it as a tool to improve collaboration, provide feedback, and recognize effort, not as a singular performance metric.

<CtaGetStarted />


# Applications
Source: https://docs.sweetr.dev/platform/applications

Manage deployable units within your repositories.

## Demo

<Frame>
  <img />
</Frame>

## How it works

Applications represent deployable units within your repositories. They connect a repository to its deployments and environments, making it possible to track deployment history and DORA metrics per application.

Applications support **monorepo setups**. A single repository can have multiple applications, each mapped to a subdirectory.

## Creating applications

Applications can be created in two ways:

* **Manually**: Create an application from the UI and configure its deployment settings.
* **Automatically**: When a deployment is sent via the API, Sweetr auto-creates the application if it doesn't exist.

## Deployment settings

Each application has configurable deployment settings that control how deployments are tracked:

| Setting           | Description                                                         |
| ----------------- | ------------------------------------------------------------------- |
| **Trigger**       | How deployments are created: API Webhook or PR Merge.               |
| **Target branch** | For merge-based triggers, the branch that represents production.    |
| **Subdirectory**  | For monorepos, the path within the repository for this application. |

## Archiving

Applications that are no longer in use can be archived. Archived applications are hidden from filters and excluded from metrics. You can unarchive them at any time.

## Related

<CardGroup>
  <Card title="Deployments" icon="rocket" href="/platform/deployments" />

  <Card title="DORA Metrics" icon="chart-line" href="/metrics-and-insights/dora" />
</CardGroup>

<CtaGetStarted />


# Code Reviews
Source: https://docs.sweetr.dev/platform/code-reviews

List of a person's code reviews.

## Demo

<Frame>
  <img />
</Frame>

## Indicators

Each code review has an indicator for whether it was the Pull Request's first review.

<PrBadge type="first-to-review" />

The indicator can also change color depending on time elapsed between the Pull Request being "ready" and the review timestamp.

<ColorBadge label="< 2 hours." />

<ColorBadge label="> 2 hours." />

<Accordion title="What ready means">
  The timestamp used for being "ready" is calculated based on what is available first:

  * The timestamp of the first review request.
  * Or the timestamp when the Pull Request was opened. A draft isn't considered open.
  * Or the timestamp the Pull Request was created.

  <Accordion title="Examples">
    - A Pull Request that got reviewed while in draft state, without requesting reviews, would use the Pull
      Request creation time.
    - A Pull Request that got created in draft, converted to open, and then got reviewed without ever requesting reviews, would use the
      timestamp of when it was converted to open.
    - A Pull Request that got created in draft, and requested multiple reviewers, would use the timestamp of the first review request.
  </Accordion>

  While this may seem overly complex, it's important so that the time elapsed calculation is fair for developers.
</Accordion>

<Info>Weekends are not included when calculating time elapsed.</Info>

## Use cases

* Easily see a developer's code reviews in one place. Quickly open the pull requests and go through the comments.
* Spot LGTM stamps in a glance (number of comments vs Pull Request size).
* Coach a developer into becoming a better reviewer.
  * Assess their communication style.
  * Assess the depth of their reviews.
  * Assess review frequency.

<CtaGetStarted />


# Deployments
Source: https://docs.sweetr.dev/platform/deployments

Track every deployment across your applications and environments.

## Demo

<Frame>
  <img />
</Frame>

## How it works

Deployments track when a version of an application is deployed to an environment. Each deployment records the version, commit hash, environment, and linked pull requests.

Filter deployments by application, environment, and date range to find exactly what you need.

## Setting up deployments for DORA Metrics

To get accurate [DORA metrics](/metrics-and-insights/dora), you need to track deployments in Sweetr.

<Steps>
  <Step title="Create an application">
    Deployments belong to [Applications](/platform/applications). Create at least one application for each deployable unit in your repositories.

    You can create applications manually from the UI, or let Sweetr auto-create them when you send your first deployment via the API.

    <Tip>
      If you have a monorepo, create a separate application for each service and configure its **subdirectory** so pull requests are correctly linked to the right application.
    </Tip>
  </Step>

  <Step title="Choose a deployment trigger">
    Each application needs a deployment trigger so Sweetr knows when a deployment happens. Pick the one that fits your workflow:

    <CardGroup>
      <Card title="API Webhook" icon="webhook">
        Call the [POST /v1/deployments](/api-reference/deployments/create-deployment) endpoint from your CI/CD pipeline (e.g., GitHub Actions, GitLab CI, Jenkins) whenever a deployment completes. **Recommended** for the most accurate metrics, since it captures the real deployment time.
      </Card>

      <Card title="Pull Request Merge" icon="git-merge">
        Automatically create a deployment when a pull request is merged to a target branch. Simpler to set up, but uses the merge time as an approximation of deployment time.
      </Card>
    </CardGroup>

    Configure the trigger in your application's **Deployment settings**. For merge-based triggers, set the **target branch** to the branch that represents production (e.g., `main`).
  </Step>

  <Step title="Send your first deployment">
    Trigger a deployment by calling the API or merging a pull request to your target branch. Sweetr will record it and start building your DORA metrics.
  </Step>

  <Step title="Backfill historical data">
    Want DORA metrics from day one? Start with the **Pull Request Merge** trigger, then go to **Settings → Workspace** and click **Resync all historical data**. Sweetr will create deployments for every previously merged PR to your target branch, giving you historical metrics right away.

    Once you have your baseline, you can switch to the **API Webhook** trigger for more accurate deployment times going forward.

    <Tip>
      This is a great way to get visibility into your team's delivery history without waiting for new deployments to come in.
    </Tip>
  </Step>
</Steps>

## Change type

Sweetr automatically determines the **change type** for each deployment by comparing commits against the previous deployment:

* **Forward**: A standard deployment with new changes.
* **Rollback**: The deployment reverts to a previous version.
* **No Change**: A redeployment of the same version.

### Linking Pull Requests

Each deployment is automatically linked to the pull requests it contains. The linking strategy depends on the deployment trigger.

#### API Webhook

When a deployment is received via the API, Sweetr compares the deployment's commit hash against the previous deployment's commit hash using GitHub's [compare API](https://docs.github.com/en/rest/commits/commits#compare-two-commits). All merged pull requests whose merge commit falls within that range are linked to the deployment.

For monorepo applications with a configured subdirectory, only pull requests that modified files within that subdirectory are linked.

<Note>
  The first deployment for an application/environment pair is marked as a
  **baseline** and has no linked pull requests, since there is no previous
  deployment to compare against.
</Note>

#### Pull Request Merge

When a deployment is triggered by a pull request merge, the linked pull request is always the one that was merged. No commit comparison is needed.

## Data quality

The deployment trigger you choose affects the accuracy of your [DORA metrics](/metrics-and-insights/dora), specifically **Change Lead Time** and **Deployment Frequency**.

<CardGroup>
  <Card title="API Webhook" icon="webhook">
    Records the **actual deployment time** as reported by your CI/CD pipeline.
    This provides the most accurate time-to-deploy calculations since it
    captures the real moment your code reaches production.
  </Card>

  <Card title="Pull Request Merge" icon="git-merge">
    Uses the **merge time** as the deployment time. This is an approximation,
    since the actual deployment typically happens after the merge, once your
    CI/CD pipeline finishes building, testing, and deploying.
  </Card>
</CardGroup>

For the most accurate metrics, prefer using the API Webhook trigger so that Sweetr captures when your code was actually deployed, not just when it was merged.

## Archiving

Deployments that are no longer relevant can be archived. Archived deployments are excluded from metrics. You can unarchive them at any time.

## Related

<CardGroup>
  <Card title="Applications" icon="cube" href="/platform/applications" />

  <Card title="Incidents" icon="flame" href="/platform/incidents" />

  <Card title="DORA Metrics" icon="chart-line" href="/metrics-and-insights/dora" />

  <Card title="API Reference" icon="code" href="/api-reference/deployments/create-deployment" />
</CardGroup>

<CtaGetStarted />


# Environments
Source: https://docs.sweetr.dev/platform/environments

Organize deployments by environment to track metrics across your deployment targets.

## Demo

<Frame>
  <img />
</Frame>

## How it works

Environments represent deployment targets like `production`, `staging`, or `qa`. Deployments are always associated with an environment, and metrics can be filtered by environment.

A default **production** environment is created for every workspace. Additional environments are created automatically when a deployment is sent via the [API](/api-reference/deployments/create-deployment) with an environment name that doesn't exist yet.

<Note>
  Environments named `production` or `prod` (case-insensitive) are automatically
  marked as production environments.
</Note>

## Production flag

Each environment has an `isProduction` flag. This matters because DORA metrics default to production environments only. Non-production deployments are excluded unless you explicitly filter for them.

## When to use multiple environments

For most teams, the default `production` environment is all you need. Multiple environments are useful when:

* **You want to measure metrics for non-production environments**, for example, tracking deployment frequency to staging.
* **You have multiple production environments**, for example, regional deployments (`production-us`, `production-eu`). Since only exact names `production` or `prod` are auto-detected, you must explicitly set the production flag for regional environment names.

## Archiving

Environments that are no longer in use can be archived. Archived environments are hidden from filters and excluded from metrics. You can unarchive them at any time.

## Related

<CardGroup>
  <Card title="Deployments" icon="rocket" href="/platform/deployments" />

  <Card title="Applications" icon="cube" href="/platform/applications" />

  <Card title="DORA Metrics" icon="chart-line" href="/metrics-and-insights/dora" />
</CardGroup>

<CtaGetStarted />


# Incidents
Source: https://docs.sweetr.dev/platform/incidents

Track production incidents caused by deployments.

## Demo

<Frame>
  <img />
</Frame>

## How it works

Incidents represent production issues caused by a deployment. They track the full lifecycle from detection to resolution, linking back to the deployment that caused the issue and the deployment that fixed it.

## Key fields

| Field                | Description                                          |
| -------------------- | ---------------------------------------------------- |
| **Cause deployment** | The deployment that introduced the issue (required). |
| **Fix deployment**   | The deployment that resolved the issue.              |
| **Detected at**      | When the incident was detected.                      |
| **Resolved at**      | When the incident was resolved.                      |
| **Team**             | The team responsible for the incident.               |
| **Leader**           | The person leading incident response.                |
| **Postmortem URL**   | Link to the postmortem document.                     |

## Creating incidents

Incidents can be created in two ways:

* **Manually**: Create an incident from the UI, linking it to the deployment that caused it.
* **Automatically**: Use the [Incident Detection](/automations/incident-detection) automation to detect incidents from rollbacks, hotfixes, and reverts.

## Impact on metrics

Incidents directly feed into two DORA metrics:

* **Change Failure Rate**: The percentage of deployments that caused an incident.
* **Mean Time to Recovery**: The average time between incident detection and resolution.

## Archiving

Incidents that are no longer relevant can be archived. Archived incidents are excluded from metrics. You can unarchive them at any time.

## Related

<CardGroup>
  <Card title="Incident Detection" icon="circle-dot" href="/automations/incident-detection" />

  <Card title="Deployments" icon="rocket" href="/platform/deployments" />

  <Card title="DORA Metrics" icon="chart-line" href="/metrics-and-insights/dora" />
</CardGroup>

<CtaGetStarted />


# Integrations
Source: https://docs.sweetr.dev/platform/integrations

The tools we integrate with.

## Available today

<CardGroup>
  <Card title="GitHub" icon="github">
    Syncs metadata from GitHub. Enabled by default.
  </Card>

  <Card title="Slack" icon="slack">
    Allows automations to send messages to Slack channels.
  </Card>
</CardGroup>

## Coming soon

<CardGroup>
  <Card title="🔜 Teams" />

  <Card title="🔜 Discord" />

  <Card title="🔜 PagerDuty" />

  <Card title="🔜 Incident.io" />

  <Card title="🔜 Jira" />

  <Card title="🔜 Linear" />

  <Card title="🔜 GitLab" />

  <Card title="🔜 BitBucket" />

  <Card title="🔜 Google Calendar" />
</CardGroup>

<CtaGetStarted />


# People
Source: https://docs.sweetr.dev/platform/people

A directory of your organization's people.

## Demo

<Frame>
  <img />
</Frame>

## Managing people

<Frame>
  <img />
</Frame>

The list of members is 100% synced with your GitHub organization.

You can't directly add or remove people in our dashboard. When a user is invited or removed from your organization in GitHub, that change is automatically synced in Sweetr.

<Warning>
  When someone is removed from your GitHub organization, their historical data
  (pull requests, code reviews) is currently removed from Sweetr as well. Data
  preservation for past members is planned.
</Warning>

## Explore

<CardGroup>
  <Card title="Code Reviews" icon="code" href="/platform/code-reviews" />
</CardGroup>

<CtaGetStarted />


# Pull Requests
Source: https://docs.sweetr.dev/platform/pull-requests

Filterable list of a team's pull requests.

## Demo

<Frame>
  <img />
</Frame>

## Size

The pull request size is calculated based on the amount of lines changed.

<PrSize label="< 20 lines changed." />

<PrSize label="20~100 lines changed." />

<PrSize label="100~250 lines changed." />

<PrSize label="250~500 lines changed." />

<PrSize label="> 500 lines changed." />

Customize how PR size is calculated in your workspace settings.

## Indicators

Each pull request has indicators regarding the time to review, approve and merge.

<CardGroup>
  <Card title="Informational">
    <PrBadge type="no-review" />

    <PrBadge type="reviewed" />

    <PrBadge type="approved" />
  </Card>

  <Card title="Alerts">
    <PrBadge type="merged-no-review" />

    <PrBadge type="stuck-review" />

    <PrBadge type="stuck-merge" />
  </Card>
</CardGroup>

The color of the icons also changes depending on the time elapsed for the corresponding event.

<ColorBadge label="< 2 hours." />

<ColorBadge label="2~24 hours." />

<ColorBadge label="24~48 hours." />

<ColorBadge label="> 48 hours." />

<Info>Weekends are not included when calculating time elapsed.</Info>

<Info>
  Color thresholds are not configurable today. Customizable thresholds are
  planned.
</Info>

## Use cases

* Easily see all team PRs in one place.
* Identify blocked PRs.
* Identify PRs with a lot of comments that might need attention.
* Get a grasp on PR size. Encourage the team to create smaller PRs for faster cycle time.

<CtaGetStarted />


# Teams
Source: https://docs.sweetr.dev/platform/teams

A directory of your organization's teams.

## Demo

<Frame>
  <img />
</Frame>

## Creating a team

Click the "New" button in the team list page to create a new team.

<Frame>
  <img />
</Frame>

## Members

<Frame>
  <img />
</Frame>

A person can belong to multiple teams. Each member can have a specific role within a team. Roles are informational labels that help viewers understand each person's function on the team. They do not affect permissions or metrics.

* Engineer
* Product
* Designer
* QA
* Leader
* Manager

## Archiving

Teams that are no longer active can be archived. Archived teams are hidden from filters and excluded from metrics. You can unarchive them at any time.

## Explore

<CardGroup>
  <Card title="Team Pull Requests" icon="git-pull-request" href="/platform/pull-requests" />
</CardGroup>

<CtaGetStarted />