GitLab: "This job does not have a trace." after an upgrade
GitLab documents this error for GitLab Self-Managed instances upgraded to 18.0 or later (job logs, troubleshooting). It can come from an upgrade migration that failed on an instance with both of these:
- Object storage enabled.
- Incremental logging turned on earlier with the feature flag
ci_enable_live_trace, which GitLab 18.0 removed. GitLab says this flag is on by default in deployments made with the GitLab Environment Toolkit or the Helm chart, and it may also have been turned on by hand.
This job does not have a trace.
Why an upgrade can cause it
Incremental logging used to be that feature flag. GitLab 17.11 replaced the flag with an instance setting, and GitLab 18.0 removed the flag (history of the setting). With incremental logging, the runner sends the log in pieces, GitLab keeps them in Redis and moves every 128 KB to a persistent store, and when the job is finished a Sidekiq worker archives the log to object storage. Without it, the pieces are cached on disk until a background job archives the log (incremental logging).
What to do
The fix GitLab gives: turn incremental logging on again, and the logs of the affected jobs show. You need administrator access, and object storage configured for CI/CD artifacts, logs and builds.
- In the Admin area: select Admin, then Settings > CI/CD, expand Job logs, and under Incremental logging configuration select Turn on incremental logging. Then Save changes.
- With the settings API: the same setting is
ci_job_live_trace_enabled(application settings API).
curl --request PUT --header "PRIVATE-TOKEN: your-admin-token" \ --url "https://gitlab.example.com/api/v4/application/settings" \ --data "ci_job_live_trace_enabled=true"
To look first, read GET /application/settings as an administrator and find ci_job_live_trace_enabled. When you turn it on, jobs already running keep writing their logs to disk, and new jobs use incremental logging (configure incremental logging).
What the API answers for such a job
The jobs API has no such message. In the source of GitLab (lib/gitlab/ci/trace.rb and lib/api/ci/jobs.rb, read on October 28, 2026), the log route GET /projects/:id/jobs/:job_id/trace looks for the archived log, then for the incremental pieces of the log, then for a log file on disk, and when it finds none it answers 200 with an empty body. A tool that reads the API therefore sees an empty log, as for a job that has not written anything yet or one whose log was erased; see why a job log is refused or empty.
GitLab job logs in IntelliJ IDEA
Pipeline Inbox for GitLab CI, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the pipelines of your GitLab projects with their jobs, and opens the log of a job in a console viewer at the bottom of the IDE, in the colours of the log, following a running job as it writes. It reads logs through the API, so for jobs like these it says that the finished job has no log, with the status of the job; the fix is on the server, as above. 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 job log refused or empty · GitLab pipeline or job refused (400, 403, 409, 429) · GitLab "Insufficient permissions to set pipeline variables" · GitLab 404 "Group Not Found" · GitLab "insufficient_scope" · GitLab pipeline plugins for IntelliJ IDEA, compared · 日本語