Croft adds built-in monitoring to every app

Croft's blog post, dated September 22, 2026 and written by Rich Chetwynd, describes a gap that opened as more people built apps by talking to Claude or ChatGPT. Those apps worked, got shared with teams, and became part of how a business ran — then broke, with the team seeing only "something went wrong" while the assistant that wrote the code saw nothing at all. Traditional monitoring tools require an account, an SDK wired into the code, and usually an engineer to set up and read the results, which the post argues does not fit someone who built an app in an afternoon by conversation.

The fix Croft proposes is to make monitoring part of the platform rather than a separate product. Alongside response time breakdowns, throughput and failure rate charts, error groups, slow request waterfalls, slowest SQL, 7 days of logs, health checks, and deploy markers, Croft exposes three MCP tools — app_errors, app_metrics, and logs — so the same assistant that wrote the code can read the error, see the logs and stack trace, fix the code, and redeploy. A Fix with Build button does the same by handing the stack trace and logs to Croft Build. Alerts are capped at once per app per day across three triggers: a new error, a high failure rate, and an unhealthy app.

What this hinges on is whether the assistant can reliably turn a stack trace and logs into a correct fix and redeploy it without a human stepping in, and whether keeping logs, errors, and traces on the customer's own server — with only aggregate counts and timings reaching the control plane — is enough for teams that care where their telemetry lives. For the people who built these apps by conversation rather than by engineering, the appeal is that the repair path now uses the same skill they already have: asking the assistant.