Activity and job logs
Dokku Pro records every command it runs on your behalf - both the synchronous commands that execute inside an API request (such as config:set) and the background jobs that run on the queue (such as ps:rebuild). Each record captures who triggered the command, the app and/or service it targeted, its outcome, and its output, so you can see an app's recent background jobs, read a job's logs as it runs, and audit what a user has done.
What is captured
For every command Dokku Pro runs in-process it stores:
- the command and its arguments, with secret values redacted
- the user who triggered it and how it was triggered (api, webhook, or git)
- the app and/or service it targeted (a link touches both)
- its mode (synchronous or background), CRUD operation, status, exit code, and timings
- its lineage - the request that triggered it and the command that spawned it
- its output, for background and other write commands, tailed live while running
Read commands (the many *:report/config:export lookups behind a page load) are recorded as metadata only and hidden from the default views to keep the audit focused on changes. Add ?include=reads to a request to include them.
Access control
Viewing an app's or service's job logs requires being associated with it and holding the job:read command in one of your teams (or full * access). Global admins always have access, and a resource's own internal team grants access to its members. A user's activity audit is visible only to that user or to a global admin.
Secrets
Command arguments and output are redacted before they are stored. Config values (config:set, config:export), auth passwords, git credentials, datastore credentials, connection strings, and reset tokens are masked, along with any credentialed URL or --password/--token/--secret flag value.
App lifecycle
An app's activity follows the app through renames and destroys, whether the change happens in Dokku Pro or through the dokku CLI:
- Renaming an app (in the UI or via
dokku apps:rename) moves its activity history to the new name. - Destroying an app (in the UI or via
dokku apps:destroy) purges all of its activity, so a later app created with the same name starts with a clean history. The destroy action itself remains in the acting user's activity audit.
Retention
Write-command records are kept for 90 days by default (ACTIVITY_TTL, in minutes). Read-command records and all command output are kept for the shorter log retention (LOG_TTL, default 7 days). A background job running during an upgrade is not carried over and must be re-triggered.
Endpoints
GET /@api/apps/{app}/queueJobs- an app's recent background jobsGET /@api/services/{type}:{name}/queueJobs- a service's recent background jobsGET /@api/users/{username}/activity- a user's recent activity (admin or self)GET /@api/queueJobs/{id}- a single command, with its lineageGET /@api/queueJobs/{id}/logs- a job's captured output, read in one request (used for finished jobs)ws /@api/queueJobLogs/{id}- a running job's logs, tailed live until it completes