stderr of the running targets can be kept on the disk by specifying -k
option (or by setting $REDO_LOGS=1 environment variable) to redo. You
can simultaneously use also -s option ($REDO_SILENT=1) to silence stderr
output, but still keeping it on the disk for possible further debug
investigation. *Only* the latest build is kept, previous one is
overwritten.

    $ redo -xx -k -s build-the-whole-huge-project

Logs are stored in corresponding .redo/tgt.log file.
Each line of it is prefixed with
=> TAI64N timestamp
that you can decode with tai64nlocal utility from
  => daemontools
or similar one:
    $ cd goredo/src
    $ go build -mod=vendor -o tai64nlocal go.cypherpunks.su/tai64n/v4/cmd/tai64nlocal

When -k is in use, all environment variables, working directory, command
line arguments, start/finish times, duration, participated PIDs, return
codes are also saved in corresponding .redo/tgt.log.rec file.

You can view any target's output with [cmd/redo-log] command (possibly
piping to tai64nlocal). -c option also shows how exactly it was started,
when started/finished and how long did it take.

-r option enables recursive serialized indented output. When you run
redo in parallel, then all stderr (if no (-s)ilence was enabled) is
printed as it appears, mixing output from all commands, that is hard to
read and investigate. Serialized redo-log output rearranges output. I
will take example from original apenwarr's idea
=> article
Serialized output will look like this:

    $ redo-log -r A
    A: ...A stuff...
    A: redo-ifchange J
    J: > redo J
    J: > ...J stuff...
    J: > redo-ifchange X Y
    X: > > redo X
    X: > > ...X stuff...
    X: > > done X
    J: > > redo Y
    Y: > > ...Y stuff...
    Z: > > > redo Z
    Z: > > > ...Z stuff...
    Z: > > > done Z
    Y: > > ...more Y stuff...
    Y: > > done Y
    J: > ...more J stuff...
    J: > done J
    A: ...more A stuff...

It will output depth first logs. It can rearrange some "events" (redo
invocations): failed targets will be at the very end, because they are
the most interesting ones for the human.

Pay attention that recursive output is more CPU hungry. Single target
output is literally copying of .redo/tgt.log file to stdout.