---
url: /en/build/login-debug.md
description: >-
  Explains how to use the Login Debugging feature to SSH into a pipeline's
  Docker container for troubleshooting CI build failures that don't reproduce
  locally.
---
## When is Login Debugging Needed?

User scripts execute inside a Docker container. Differences between local and CI environments may cause
build failures that don't occur locally. In such cases, use the "Login Debugging" option on the logs page
to access the container for troubleshooting.

## How to Use?

A Docker container is started during pipeline execution to run user scripts.
The container is destroyed after the build completes by default,
so debugging must be done while the environment is still alive.

Login debugging is available in two scenarios:

1. **During the build**: Click "Login Debugging" directly
2. **After the build**: Check the `Debug` option (next to `Rebuild`) on the logs page, then click `Rebuild`.
   The environment is retained for 5 minutes after the newly triggered build completes.
   The system periodically checks if anyone is logged in: if not, the environment is destroyed;
   if yes, it continues to be retained for a maximum of 1 hour.

## Debugging Tips

When clicking `Rebuild`, you can select which `Pipeline`, `Stage`, or `Job` to execute,
helping to reproduce the problem environment.

For example, if the build fails at the `install` stage and you suspect the
dependency install command behaves differently than locally, you can select
only that stage to re-run, then click "Login Debugging" to enter the container
and check whether the artifacts (such as `node_modules`) match the local ones.

> Tip:
>
> * When you select specific Pipeline, Stage, or Job, the unselected jobs are
>   not executed, which helps quickly locate which step fails.
> * If the selected Stage depends on preceding tasks (such as artifacts or
>   dependencies), select those preceding tasks together as needed. Otherwise,
>   the re-run may fail due to missing prerequisites.