Skip to main content

Ability to remove specific logs / post-processing as it's own step

Feature RequestsLogs

We are running a monorepo of terragrunt modules and providers, that get planned and applied using run-all. This means that there is a large amount of logs lines for the post processing that Spacelift does, such as Analyzing plan for module... and Generating JSON representation of the plan...

The logs viewer in the web UI is very restricted with the number of lines it shows, so the useful terragrunt logs are hidden and the logs viewer rendered useless.

It would be nice to have the post processing run as it’s own step or the ability to remove specific logs from the output so we can just see what’s important to the plan.

I tried to workaround the issue by running terragrunt show as an after plan hook, but the post-processing logs are still the last thing written.

Workaround
No
Problem
Status: 🗑️ Archived4 comments

Log in to comment and vote

Comments4

  • Natalia Gazda

    Team•

    Jul 16

    Hey, thanks for the suggestion. We're archiving this one for now. It hasn't picked up much interest since it went up, so it isn't on our near-term roadmap. Archiving isn't deleting: the request stays on record, and if it gathers more votes or comments we can bring it back. If it still matters to you, add a vote or a comment so we can gauge the demand.

  • Harlequin Star

    •

    May 12, 2025

    Hey @Marcin Wyszynski, thanks for following up on this. I agree with your assessment, whilst it is noisy logging the root cause is really that critical information gets buried.

    For our particular case, we are trying to spot errors. It would be awesome if errors were directly exposed in the UI when a job fails.

    This matters most for the debugging use case, where you might get a failed plan or a failed apply. The cost of the current workaround is having to download the log, have a text editor configured to read the log in a readable way (e.g. VS Code with ANSI Colors plugin enabled) then search and find the error. Regularly we have engineers who don’t work with terraform in their day to day trying to search thousands of log lines for an error they aren’t familiar with. This is a level of toil that if removed could make there experience better, but also make the UX of the Spacelift UI better. Direct exposure of errors feels like a great win!

  • Black Breeze

    •

    May 10, 2025

    Thanks for raising this! We want to dig deeper into the real need here.

    It sounds like the issue isn’t just removing logs—it’s that critical info gets buried, and with the viewer’s size limits, that info might not be visible without downloading the whole file.

    We’d love to understand more:

    • What are you trying to spot—errors, diffs, secrets?

    • When does this matter most—debugging, approvals, incidents?

    • What’s the cost of the current workaround (e.g., downloading and searching)?

    If we understand what “finding the signal” means for you, we can explore whether the right fix is suppression, filtering, search, or something else entirely.

    Appreciate the insight—this is pointing at a deeper need.

  • Azure Breeze

    •

    Apr 16, 2025

    Buildkite has a nice feature about this, allowing to create section within the log outputs. It would be great to have such thing for Spacelift.