{"id":2505,"date":"2026-02-19T18:54:21","date_gmt":"2026-02-19T17:54:21","guid":{"rendered":"https:\/\/craft-coders.de\/3bpizkrx8k\/codegeist-2025-forge-log-dashboards-for-bitbucket\/"},"modified":"2026-02-19T19:00:30","modified_gmt":"2026-02-19T18:00:30","slug":"codegeist-2025-forge-log-dashboards-for-bitbucket","status":"publish","type":"post","link":"https:\/\/craft-coders.de\/3bpizkrx8k\/codegeist-2025-forge-log-dashboards-for-bitbucket\/","title":{"rendered":"What We Built for Codegeist 2025: Forge Log Dashboards for Bitbucket"},"content":{"rendered":"

In 2025, we joined Codegeist<\/strong> again and used the opportunity to build something that had been on my mind for a while: better observability for Forge apps without immediately spinning up a full external stack.<\/p>\n

Our project is Forge Log Dashboards for Bitbucket<\/strong> (Devpost entry: Advanced Dashboards for Forge Logs<\/a>).<\/p>\n

The core question behind it was simple: when a Forge app grows beyond \u201csmall utility,\u201d how do you investigate behavior quickly without context-switching all the time?<\/p>\n

Why we built this during Codegeist<\/h2>\n

In day-to-day app work, logs are usually where debugging and incident analysis starts. Forge gives you built-in logging, which is great. But as soon as complexity increases, you start needing richer filtering, comparisons over time, and repeatable views for your team.<\/p>\n

For this hackathon, I wanted to explore a middle ground: keep analysis close to development work, inside Atlassian tooling, and still get more analytical depth than plain log browsing.<\/p>\n

What we built<\/h2>\n

We built dashboards directly inside Bitbucket with widget-based visualizations and query-driven exploration.<\/p>\n

    \n
  • Dashboard widgets can be added, moved, resized<\/li>\n
  • Log data can be explored with SQL-style queries<\/li>\n
  • Dashboards can be shared\/exported as JSON<\/li>\n
  • Starter content helps with onboarding and testing<\/li>\n<\/ul>\n

    Technically, the solution combines Forge backend components with a frontend-heavy analysis approach for responsiveness.<\/p>\n

    What I personally learned from this project<\/h2>\n

    1) Log quality matters more than log quantity.<\/strong>
    \nThe biggest improvement is often not \u201cmore logs,\u201d but cleaner and more structured logs. Once fields are consistent, analysis gets dramatically easier.<\/p>\n

    2) Developer UX is a feature, not a luxury.<\/strong>
    \nIf dashboards are slow or clunky, people stop using them. Fast feedback loops are essential for real debugging workflows.<\/p>\n

    3) Good defaults reduce friction.<\/strong>
    \nDemo data and starter dashboards made it much easier to explain and test the concept quickly.<\/p>\n

    4) Platform limits shape architecture early.<\/strong>
    \nRequest\/payload constraints force good engineering decisions around data transport, caching, and incremental loading.<\/p>\n

    The hackathon reality<\/h2>\n

    Like many hackathon projects, this one had a chaotic side as well \u2014 and for us it got very real in the final stretch. Shortly before the deadline, one developer laptop crashed and we suddenly had to recover parts of our work under serious time pressure. That changed the mood from “let\u2019s polish” to “let\u2019s rescue what matters most”: stabilize the core flow, keep the demo working, and make hard trade-offs about what to cut.<\/p>\n

    In hindsight, that moment was frustrating, but also one of the most valuable parts of the whole experience. It forced us to communicate clearly, prioritize brutally, and focus on what actually delivers value to users \u2014 not what looks fancy in a hackathon demo. That pressure test taught us more about our architecture and team workflow than a smooth week ever could.<\/p>\n