Making our controllers more observable is something we have been working on for a while. The first step in the journey was to introduce more descriptive and consistent status and events across all Kratix-owned resources (for example, check the Promise status and events). Together with additional printer columns for the kubectl get command, this represented a great improvement to the user experience of operating a platform that uses Kratix.
side note: I often say destination statuses were the best feature we ever implemented in Kratix. Time has been proving me right:
The next problem we wanted to tackle was logs. Whenever an error occurred, our customers would need to go through a painful journey sifting through hundreds of lines of logs to attempt to find the one line that contained the right error. Kratix output a range of logs at different levels, all unstructured. We often caught ourselves on customer support calls just to point out to them that the error is right there, line 5675 of the logs. We needed to do better.
So back in June 2025 the team at Syntasso got together to explore how we could make discovering what went wrong when their platform is not behaving the way they expected easier. The results of that session were a series of guidelines and best practices for logging that we should follow when building out controllers. In this blog post, we will go through those guidelines, how we implemented them, and the results we have seen so far.
