Errors

Errors collects everything that broke in one place. It has two sources:

• The agent's commands: the build, type checks, tests, lint and scripts it runs while it works. There's nothing to install.
• Your live app: what breaks for the people using your app in production. You connect it once with /faundr:errors-setup.

Every error becomes an E-n. Errors from commands stay linked to the conversation and request they came from, so you know what caused each one.

Errors from the agent's commands

After every check command, Faundr reads the output on your computer:

• if it failed, Faundr splits out each error (just the message and a short excerpt, with keys masked) and sends it to the dashboard;
• when the same command passes again, the error closes on its own;
• if it shows up again after closing, it gets the Regressed tag.

Commands like git, grep and the dev server are left out. At the start of every session, the agent is told about the open errors.

This works in every language Faundr covers except plain HTML, which has no command to run. Faundr understands the output of tsc, ESLint, Vitest and the other JavaScript tools, plus mypy, ruff and pytest (Python), go build, go vet and golangci-lint (Go), cargo build and cargo clippy (Rust), flutter analyze and flutter test, Maven and Gradle, dotnet build, phpstan and phpunit (PHP), gcc, clang, make and ctest (C/C++), and docker build. These tools only show up here if your project already uses them. Faundr doesn't install any of them. The full table is in Supported languages.

Errors from your live app

With /faundr:errors-setup, the agent installs Sentry's free SDK in your app, pointed at Faundr:

• you don't need a Sentry account;
• it only sends errors, only from production, and without personal data;
• every published version is tagged with its commit, so you know which version an error appeared in.

It works with JavaScript and TypeScript (React, Next.js, Vue, Nuxt, Svelte, Angular, React Native, Node, Cloudflare Workers and plain HTML sites), Python, Flutter and Dart, PHP and Laravel, Go, Java and Kotlin (Spring Boot and Android), C#, Rust, C and C++.

At the end, the agent verifies the setup with a test error.

For a live app error, the detail view shows how many people were affected, on which page, in which version, where it broke in the code and what the person did before the error. For JavaScript, the original code is recovered from the *source maps* on your computer, without sending anything to anyone.

Tabs

Errors

The status card shows how many errors are open, how many came back and how many are spiking. It also has the Fix with AI button. Filter by type (Live app, Build, Types, Tests, Lint, Scripts) and by status (Open, Resolved, Archived).

The tags:

• Regressed: it was fixed and showed up again;
• Spiking: the live app error is happening far more than usual this hour;
• Waiting for deploy: fixed, waiting for the new version to go live.

An error's detail view has:

• In plain language: what it is, why it usually happens and what to do;
• Copy prompt for your agent: a ready-made request that works with any AI coding agent;
• where it broke, how many times, where it started (conversation and request) and the output excerpt.

And the buttons:

• Fix with AI (/faundr:error-fix E-n): the agent fixes the cause without silencing the error, and only marks it resolved once the same command passes again;
• Archive for 7 days or Archive until it recurs;
• live app only: Resolved in next deploy (the old version can keep sending the error without reopening it; it only comes back if it shows up in a new version) and For 100 more events (archives the error until it happens 100 more times).

By session

Errors grouped by the conversation they came from: how many started there, how many are still open and how many were resolved in the same conversation. It helps you see whether a session left damage behind.

Live app

Everything that connects your live app to Faundr:

• Status card: whether errors are arriving and when the last one came in, with the Connect app button (/faundr:errors-setup).
• Ingest URL (DSN): the address your app uses to send errors, with the limits (above 300 events per hour, Faundr keeps a sample).
• Uptime: Faundr checks your site every 5 minutes. If it goes down (2 failures in a row), a "Site down" error is created and you get an alert. When the site comes back, the error closes on its own. Only https addresses are accepted.
• Slack or Discord alerts: paste a channel's webhook URL and pick the alerts: New error, Error regressed, Error spiking and Site down and back up. At most one alert per error per hour. The same webhooks are used for the weekly Activity summary.
• CSP reports (optional): the snippet that makes your security header send violations to Faundr.
• Already using Sentry?: the command to bring your open errors over from there.

Findings from your own skills

If you already use a skill for tracking down bugs, failures or logs that isn't Faundr's, you can connect it to the dashboard with /faundr:skills. Every time it runs, the agent records what it found at the end of the response:

• each error becomes an E-n here, tagged via /name, and counts toward Launch and Insights like any other;
• when the skill runs again and the error is gone, it closes on its own;
• each skill only closes its own findings, and only in the files it looked at.

See how to connect one in Workflows.

Commands