coollabsio/coolify · error · NonReportableException

ScheduledTaskJob failed: No valid container was found. Is th

Error message

ScheduledTaskJob failed: No valid container was found. Is the container name correct?

What it means

ScheduledTaskJob collects the resource's running containers (applications via getCurrentApplicationContainerStatus, services via running applications+databases), then executes only in a container whose name starts with '{task->container}-{resource->uuid}'. If the loop completes without a match — multiple containers and a non-matching stored name — it throws NonReportableException so the ScheduledTaskExecution row is marked failed and the scheduled-errors channel is notified without flagging an app bug.

Source

Thrown at app/Jobs/ScheduledTaskJob.php:167

                if (count($this->containers) == 1 || str_starts_with($containerName, $this->task->container.'-'.$this->resource->uuid)) {
                    $cmd = "sh -c '".str_replace("'", "'\''", $this->task->command)."'";
                    $exec = "docker exec {$containerName} {$cmd}";
                    // Disable SSH multiplexing to prevent race conditions when multiple tasks run concurrently
                    // See: https://github.com/coollabsio/coolify/issues/6736
                    $this->task_output = instant_remote_process([$exec], $this->server, true, false, $this->timeout, disableMultiplexing: true);
                    $this->task_log->update([
                        'status' => 'success',
                        'message' => $this->task_output,
                    ]);

                    $this->team?->notify(new TaskSuccess($this->task, $this->task_output));

                    return;
                }
            }

            // No valid container was found.
            throw new NonReportableException('ScheduledTaskJob failed: No valid container was found. Is the container name correct?');
        } catch (\Throwable $e) {
            if ($this->task_log) {
                $this->task_log->update([
                    'status' => 'failed',
                    'message' => $this->task_output ?? $e->getMessage(),
                ]);
            }

            // Log the error to the scheduled-errors channel
            Log::channel('scheduled-errors')->error('ScheduledTask execution failed', [
                'job' => 'ScheduledTaskJob',
                'task_id' => $this->task->uuid,
                'task_name' => $this->task->name,
                'server' => $this->server?->name ?? 'unknown',
                'attempt' => $this->attempts(),
                'error' => $e->getMessage(),
            ]);

View on GitHub (pinned to 70b9acc424)

Solutions

Edit the scheduled task and set 'Container' to the bare service name shown on the resource's container list (the part before '-uuid').
Verify with docker ps on the server that the container is running — stopped containers are excluded from the candidate list.
If the resource now has exactly one container, clear the container field so the single-container shortcut applies.

Example fix

// before: full container name stored — never prefix-matches
$task->container = 'myapp-' . $resource->uuid;
$task->save();

// after: bare service name; the job appends '-{resource->uuid}' itself
$task->container = 'myapp';
$task->save();

Defensive patterns

Strategy: validation

Validate before calling

// Before dispatching ScheduledTaskJob, verify the target exists
$containers = $resource->type() === 'application'
    ? getCurrentApplicationContainerStatus($server, $resource->id, 0)->pluck('Names')
    : $resource->applications()->get()
        ->concat($resource->databases()->get())
        ->filter(fn ($c) => str(data_get($c, 'status'))->contains('running'))
        ->map(fn ($c) => data_get($c, 'name') . '-' . $resource->uuid);
$prefix = ($task->container ?? '') . '-' . $resource->uuid;
$valid = $containers->count() === 1 || $containers->contains(fn ($n) => str_starts_with($n, $prefix));
if (! $valid) { /* flag task as misconfigured before it ever runs */ }

Try / catch

catch (NonReportableException $e) { record on the ScheduledTaskExecution log and notify the task owner with the container list — this is a config error, retrying identical input cannot succeed. }

Prevention

Store bare service names in task->container; never the full '-uuid' container name.
When renaming compose services, update scheduled tasks in the same change.
Periodically reconcile task container fields against actually running containers.

When it happens

Trigger: Scheduled task on a multi-container application or service where task->container does not prefix-match any running container name; the compose service was renamed after the task was created; only a subset of containers running so the named one is missing from the list.

Common situations: Renaming a service in docker-compose and forgetting the scheduled task; task created against one container, later more services added; entering the full container name (with -uuid) into the task's container field, which can never prefix-match.

Related errors

AI-assisted analysis of coollabsio/coolify@70b9acc424 (2026-08-17). Data as JSON: /api/errors/fad3ac488519c5e9. Report an issue: GitHub.