It is already 5 years after this crazy fundamental idea was emerged to you, why is it still not implemented? It's essential for either long-time build debugging or build time optimization, when it turns to enterprise use case, it's very common that a big project runs on CircleCi, then timestamp is very basic information facilitating deep dive! And it's even generally implemented by your competitors!

Having come from Jenkins, where I'd enabled Timerstamper globally, moving to CircleCI where no timestamps were shown anywhere felt like a massive downgrade.

I've lost count of the number of times that I've previously had to track down log entries across multiple systems (especially for security stuff), and having accurate timestamps is absolutely key to being able to do that.

CircleCI is just an information black hole by comparison to everything else.

IMO any automated system ought to make it obvious exactly when happened, and ideally when every line output from every step happened, otherwise you don't know which part of a job took much longer than normal.

TL;DR: This is a crazy functionality omission.

I'm really surprised this isn't built-in already - it's really helpful for optimising builds.

@Nathan this would be a big help. Our workflow uses rebasing so the Git commit history reflects the merge time into our lower stages leaving us with no good way to precisely timestamp prod releases.

Would love to have this. As a workaround, I'm currently piping build scripts through "ts" (part of "moreutils"):/path/to/my/script | ts

@Nathan: +1

I'm adjusting the name of this to reflect how we would likely implement this if and when it makes the backlog.