Symfony Console: Building Interactive Commands with Progress Bars and Tables

1. Why console commands are more than a cron wrapper

In a lot of projects a console command is born out of the need to automate a service call for cron, and it stays exactly as bare as it started. That's fine for a pure background job, since nobody reads a cron job's output live. But the moment the same command is also started manually by a developer or an ops colleague, say to kick off a one-off data import or reprocess a failed order, the bar for what counts as good output changes completely.

A person sitting at a terminal wants to know how far along the process is, whether it's still running at all, and in case of failure, exactly which record caused the problem. The Console component gives you three main building blocks for that: SymfonyStyle for consistent text output, ProgressBar for tracking long-running operations, and the Table helper for structured overviews. Knowing when to reach for each of these turns a command into something that serves both the cron job and the human at the keyboard equally well.

2. SymfonyStyle: the helper for consistent CLI output

SymfonyStyle wraps the plain OutputInterface and adds semantic methods such as title(), section(), success(), warning() and error(), each producing a consistently boxed layout. Instead of hand-rolling ANSI color codes or dashed separator lines in every command, you simply call $io->success('Import finished') and get a green-highlighted box that looks and behaves identically across every command in the project. That consistency turns into real time savings once a team has a dozen or more hand-written commands to maintain.

Just as useful are $io->table() for small overviews and $io->listing() for bullet lists, both of which handle indentation and line wrapping automatically, even in a narrow terminal window. SymfonyStyle also quietly handles the question of whether the output is even an interactive terminal in the first place: once output is redirected to a file, formatting falls back to plain text without color codes, so log files stay readable instead of getting cluttered with raw control characters.

3. ProgressBar for long-running batch operations

Once a command processes hundreds or thousands of records, say rebuilding a search index or sending out a newsletter campaign, plain text output per record is usually both too slow and too noisy to be useful. The ProgressBar class handles this far more gracefully: initialized with the total item count, it renders a bar with percentage, elapsed time and estimated remaining time, updating the same terminal line on every step instead of flooding the screen with hundreds of lines.

It's important not to redraw the bar on every single record, since that carries a measurable performance cost at scale. setRedrawFrequency() lets you control how often the display is actually repainted, say every 100 items, while the internal counter still advances correctly on every call to advance(). The example below shows an import command that processes products in a batch while reporting progress cleanly.

<?php

declare(strict_types=1);

namespace App\Command;

use App\Repository\ProductImportRowRepository;
use App\Service\ProductImporter;
use Symfony\Component\Console\Attribute\AsCommand;
use Symfony\Component\Console\Command\Command;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Output\OutputInterface;
use Symfony\Component\Console\Style\SymfonyStyle;

#[AsCommand(name: 'app:products:import', description: 'Imports products from the staging table')]
final class ImportProductsCommand extends Command
{
    public function __construct(
        private readonly ProductImportRowRepository $rows,
        private readonly ProductImporter $importer,
    ) {
        parent::__construct();
    }

    protected function execute(InputInterface $input, OutputInterface $output): int
    {
        $io = new SymfonyStyle($input, $output);
        $pending = $this->rows->findPending();
        $total = count($pending);

        if ($total === 0) {
            $io->success('No pending import rows found.');

            return Command::SUCCESS;
        }

        $io->title(sprintf('Importing %d products', $total));

        $progressBar = $io->createProgressBar($total);
        $progressBar->setRedrawFrequency(50);
        $progressBar->setFormat('very_verbose');
        $progressBar->start();

        $failed = [];

        foreach ($pending as $row) {
            try {
                $this->importer->import($row);
            } catch (\Throwable $exception) {
                $failed[] = sprintf('Row %d: %s', $row->getId(), $exception->getMessage());
            }

            $progressBar->advance();
        }

        $progressBar->finish();
        $io->newLine(2);

        if ($failed !== []) {
            $io->error(sprintf('%d of %d rows failed', count($failed), $total));
            $io->listing($failed);

            return Command::FAILURE;
        }

        $io->success(sprintf('%d products imported successfully', $total));

        return Command::SUCCESS;
    }
}

4. Table helper for structured output

When a command returns results made up of several columns, say a list of failed orders with ID, customer and failure reason, a tabular layout is far easier for a human to parse than a run of plain text lines. The Table helper, reachable via $io->table($headers, $rows) or directly through new Table($output) for finer control, handles the entire formatting job, including column width calculation, wrapping overly long cell content, and drawing the separator lines.

For very wide tables with many columns, setColumnMaxWidth() is worth using to cap individual columns and prevent the whole table from wrapping into an unreadable mess. For machine-readable output, say when another script needs to parse the result, a separate --format=json option that bypasses the table rendering entirely is the better fit. Keeping human-facing and machine-facing output cleanly separate is a pattern worth applying consistently across every command.

5. Interactive prompts with ask, confirm and choice

SymfonyStyle offers three core methods for prompting the user: ask() for free-form text input with optional validation, confirm() for a simple yes/no decision with a sensible default, and choice() for picking from a fixed list of options. A command that runs a database migration with potential data loss should ask confirm('Really delete all test data?', false) before proceeding, where the second argument sets the default to false, so an accidental Enter press doesn't trigger a disaster.

With ask() you can pass a validator as the third argument that checks the input immediately and re-prompts on invalid values, instead of silently processing bad data further down the line. For passwords or API keys, askHidden() keeps the input from being echoed to the terminal. Across all of these methods it's worth remembering that they only work when an interactive terminal actually exists, since in a pipeline or a cron job there's simply nobody there to answer a question.

6. When a command should be interactive, and when it shouldn't

The rule of thumb is: interactivity earns its place when a command performs a potentially destructive or hard-to-reverse action and is typically started by a human, say a deployment script that double-checks before overwriting the production database. The moment that same command is also invoked programmatically from another command, for example via $this->getApplication()->find('app:other-command')->run(), or runs on a schedule via cron, it must never wait on an answer that will never arrive.

Symfony resolves this tension with the global --no-interaction (or -n) flag, which automatically answers every prompt with its configured default, without the command's own code needing to know anything about it. Inside the command, $input->isInteractive() lets you check whether an answer can even be expected, and branch accordingly. That check is particularly valuable when a command wants to offer extra convenience features in interactive mode that simply drop away when run unattended.

7. Planning for non-interactive modes in cron and CI from day one

A common mistake is building a command interactively first and only bolting on cron-safety after the first silent timeout shows up in a production log. It's better to pair every interactive prompt with a sensible default and a dedicated command-line option from the start, say an InputOption::VALUE_NONE based --force flag that explicitly skips confirmation without depending on --no-interaction being set correctly elsewhere.

CI pipelines and cron jobs should consistently set --no-interaction as well, even if the command currently has no prompts at all, because a confirm() added later inside a shared trait would otherwise block the whole job without warning. This defensive habit costs a single extra flag when writing the cron entry, but reliably prevents processes hanging for hours, only noticed once an alert fires for exceeding the expected runtime.

8. Exit codes and error handling in commands

A command that catches an internal error and still returns Command::SUCCESS looks like a successful run to cron and CI, even though the actual task failed. The return value of execute() is therefore not a minor detail but the only reliable interface a calling system has to determine whether the job truly succeeded. Symfony defines Command::SUCCESS (0), Command::FAILURE (1) and Command::INVALID (2) for bad input parameters, and sticking to them consistently matters.

For commands that process multiple independent items, like the product import shown earlier, it makes sense to collect partial failures instead of aborting on the first error, and return an overall status that reflects whether everything, part of it, or nothing worked. Wrapping the whole command body in a top-level try/catch also catches unexpected exceptions that would otherwise land as an ugly stack trace in the cron log, replacing it with a clean $io->error() message followed by Command::FAILURE.

9. Testing console commands with CommandTester

Console commands often go untested in practice because they look like a thin wrapper around already-tested services. But the logic that actually lives inside the command itself, like option handling, output formatting, or the interplay between several prompts, stays completely unverified. Symfony's CommandTester fixes this by running a command in isolation, with no real terminal required, and exposing both its output and its exit code for assertions.

For interactive commands, setInputs(['yes', 'my-value']) simulates the sequence of answers a user would type, so ask() and confirm() calls can be exercised automatically. Combined with a separate test for the --no-interaction path, this gives you confidence that the command behaves correctly both at the terminal and in cron, without manually clicking through both variants every time.

10. Summary

11. FAQ: Symfony Console Commands: Key Takeaways