Reporting an issue

When something is wrong, tell us from wherever you are: the CLI, your agent, the console or the API. Every report reaches the BataDB team at once. An outage or an urgent report alerts us right away.

You describe the symptom. We attach the evidence: the state of your project at the moment you filed, so nobody has to ask what the compute looked like then.

From the CLI#

bata report

In a terminal it asks what kind of problem, how bad it is, one line on what is wrong, and what happened. It files the report about your linked project and prints the report id and its console link.

An agent or a CI job passes everything as flags:

bata report \
  --title "Connections fail with early eof" \
  --category outage \
  --severity urgent \
  --description "psql: early eof on every connect since 21:10 UTC" \
  --project <project-id> \
  --json

Follow it up:

bata report list                      # your team's reports and their status
bata report show <report-id>          # status, what was captured, the replies
bata report comment <report-id> --message "Still failing at 21:50"

With no terminal, --title and --category are required, and --json prints the report exactly as the API returns it. The CLI reference lists every flag.

From an agent (MCP)#

The MCP server has the same four actions: report_create, report_list, report_get and report_comment. They are in the core toolset and stay available in read-only mode, because filing a report changes nothing in your projects. Tell your agent to report when a database is down or misbehaving and it cannot fix it from its side.

From the console#

• Report an issue in the header, on every page. Opened from a project page, the report is about that project.
• Report an issue on a project's page, and Report a problem on a compute's controls, file the report about that project or compute.
• Your reports in the sidebar lists every report your team filed, with its status. Open one to read the replies and answer them.

What we attach#

When a report is filed, BataDB records what it sees for the project, branch and compute it is about:

• the compute's status and size, and whether it is always on;
• every wake in the last 24 hours and how it ended (served, failed, timed out), with timings;
• the compute's health checks in the last 24 hours;
• the project's recent operations and events;
• your plan;
• the request id of the report itself.

The CLI also attaches its own failed calls from the last day, up to ten: the method, the path, the status, the error code and the request id. Never a request body, a header, a key or a query string. Only calls made with the same login are attached, so a report filed under one profile or key never carries another's. Pass --no-errors to leave them out.

Nothing secret is ever attached: no passwords, keys, connection strings or data from your tables. Only resources your credential can already see are read. A key limited to certain projects must name one of them, and only sees reports about them.

Do not put secrets in the title, description or replies. BataDB staff read them.

What happens next#

Status changes and our replies show up on the report in the console and in bata report show. A report we tie to an incident we are already working on says so. We do not email you about reports yet.

Who can report#

Anyone on the team, viewers included, and any API key with the read scope or more. A team can file 10 reports an hour and 30 a day. Past that the API answers 429; add to an open report instead.