Ourbase isn't replacing our observability stack - it helps us navigate the application-error layer above it, the one that drags you out of flow state when developing.
One of the least enjoyable jobs.
One that, due to the noise-to-value ratio, most of the time goes unattended.
How is it doing that for us?
Takes application errors directly from our system tracking
Triages them to remove a lot of noise
Creates an MR/PR and notifies us on Slack only when there's already a fix candidate: less friction to take these on :)
With more than 50 incident MRs opened so far, many already merged (and a handful closed because there was already a fix from our side), we've started to perceive that value.
To evaluate the tool we addressed internally a metric "human-free clean rate", to measure if a MR hitting our Slack channel was actually ready to review or required "human cleanup".
The reason that ratio keeps improving on our side is that Ourbase lets us shape the agent's context - we push a per-service custom context via their API pointing at our shared library, our test conventions, our architecture standards, and our lint/mypy gates. So the first PR doesn't show up "code-shaped" - it shows up Landbot-shaped.
The flywheel that closes the loop: when a pipeline fails or our internal review bot flags something, we kick our own validation-loop agent inside the Ourbase incident chat with the same custom context and same repo access:
Failing tests
Unresolved threads
Lint issues
Get fixed in-place before a human even opens the MR. Per-service severity threshold + auto-PR toggle let us calibrate noise per repo.
In conclusion: promising tech, real value already in the workflow today, and an API surface honest enough that we built tooling around it.
PS: the team behind this product is awesome - shipping features that show they're listening to their users.
