GitLab: why the job log was refused or empty
A job's log comes from GET /projects/:id/jobs/:job_id/trace. GitLab checks three things in turn: whether your account may read the project's jobs (otherwise 403), whether the ID is a job with a log in this project (otherwise 404), and whether your account may read this job's log (otherwise 403 again). All of this is from GitLab's source (lib/api/ci/jobs.rb, app/policies/ci/build_policy.rb and Ci::Build#debug_mode?), read on October 24, 2026:
HTTP/1.1 403 Forbidden
{"message":"403 Forbidden"}
403 for the log, but the job itself opens
The job (GET /projects/:id/jobs/:job_id) skips the third check, so it answers 200 while the log answers 403. Two kinds of job have logs that GitLab shows only to people who can update the project's jobs, that is, the Developer role or higher:
- Debug logging is on for the job:
CI_DEBUG_TRACEorCI_DEBUG_SERVICESistruefor it. GitLab's documentation: with debug logging set in.gitlab-ci.ymlor in the CI/CD variables, users below the Developer role cannot see the log. It also warns thatCI_DEBUG_TRACEset as a local variable on the runner is not checked: those debug logs are visible to everyone who can see the job logs. - An agent flow ran the job: its pipeline's source is
duo_workflow. In GitLab's current source, such logs are for the Developer role and up, because they can repeat what was posted as internal notes.
403 for the job too
Then your account may not read the project's jobs at all, because of the project's CI/CD settings or your role, and the log is not the cause. A token without the read_api or api scope is refused with 403 too, but that answer says insufficient_scope; see which scope to add.
404 "404 Not found"
The log comes only from the project's builds, so a trigger job that starts a downstream pipeline answers 404: its log is in the jobs of the pipeline it started. A job ID from another project, or from a deleted pipeline, answers 404 as well.
200 with an empty body
GitLab's documentation lists 404 for a job without a log, but in the source a job without a log answers 200 with an empty body. That is a job that has not written anything yet (created, pending, manual or skipped), or one whose log was erased: POST /projects/:id/jobs/:job_id/erase removes the job's artifacts and its log.
Where it stands
curl --header "PRIVATE-TOKEN: your-token" "https://gitlab.com/api/v4/projects/GROUP%2FPROJECT/jobs/123"
status says whether the job has run. erased_at is not null when its log was erased. Use your own server's address instead of gitlab.com.
What to do
- Debug logging: ask someone with the Developer role or higher to read the log, or for that role. When the problem is found, remove
CI_DEBUG_TRACEorCI_DEBUG_SERVICES: the logs of later jobs without them are shown to everyone who can read the project's jobs. - An agent flow's job: the same: the Developer role or higher.
- 403 for the job too: ask a maintainer about your role or the project's CI/CD visibility.
- 404: for a trigger job, open the downstream pipeline and its jobs' logs. Otherwise check the job ID and the project.
- Empty: wait until the job starts. An erased log is gone; run the job again for a new one.
GitLab job logs in IntelliJ IDEA
Pipeline Inbox for GitLab CI, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists your GitLab projects' pipelines with their jobs, and opens a job's log in a console viewer at the bottom of the IDE, with the log's colours, following a running job as it writes. When a finished job has no log, it says so with the job's status; where GitLab will not give a log without a token, it says to add one (read_api is enough). From version 1.0.16, when GitLab shows the job but refuses its log (403), it says that such logs are shown only to the Developer role and up, because of debug logging or an agent flow; before, it said that the token needed the read_api or api scope. From version 1.0.20, a job whose log was erased is shown as erased, not as a job without a log. Reading is free; retrying, cancelling and running are Pro (US$1.50 a month, with a 30-day trial).
GITLAB is a trademark of GitLab Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by GitLab Inc. or JetBrains.
More: GitLab pipeline or job refused (400, 403, 409, 429) · GitLab "Insufficient permissions to set pipeline variables" · GitLab "insufficient_scope" · GitLab 401 "invalid_token" · GitLab 404 "Project Not Found" · GitLab 404 "Group Not Found" · GitLab job dropped as stuck or over its timeout · GitLab "This job does not have a trace." after 18.0 · GitLab pipeline plugins for IntelliJ IDEA, compared · 日本語