Skip to main content

Troubleshooting

Things go wrong in every build process, and Instroc is designed so that most problems fix themselves or take one click to resolve. This page walks through the situations you are most likely to hit: build errors, runtime errors, a stale preview, a change that went sideways, and the credit and permission questions that come with them.

Build errors fix themselves​

If a change from Roc breaks the build, you will see "Build error - AI is fixing..." and Roc repairs it automatically. You do not need to do anything, and the fix is free: when the AI breaks the build, the AI pays for the repair, not you. While the fix runs, the preview keeps showing the last working version of your app ("Couldn't rebuild the preview. Showing the last working version." with a Try again button), so nothing you had is lost.

Runtime errors: the red badge​

Some problems only appear when the app runs, like a page that crashes when you click a button. Instroc detects these and shows a red badge in the preview header: "N runtime errors detected. Click to fix." Click it and Roc investigates and repairs the error. Runtime error fixes are charged at a reduced credit rate, roughly a third of normal work.

The /troubleshoot command​

When something feels off but there is no error badge (a form that silently does nothing, a page that looks wrong, data that does not appear), type /troubleshoot in the chat or press the stethoscope button. Roc explores your app, finds issues, and fixes them. It is the right tool when you cannot name the problem precisely, and a troubleshoot pass costs only a small fraction of a credit per step.

Preview looks stale​

The preview is a real built app. When Roc finishes a change the app rebuilds and the preview refreshes on its own, showing an "Updating preview..." pill while it works. Rebuilds usually take a few seconds, occasionally a minute or two when the build environment is cold. If you think you are looking at old output, first check for the pill, then press the Refresh button in the preview header. Give a fresh build a moment before concluding something is missing.

Reverting a change​

Every message that changes your app can be undone. You have three layers:

  • Per-message revert. Each Roc response has a "Revert to this version" action, which takes the app back to exactly that point.
  • Version history. Toggle the history view to see the timeline (v1, v2, and so on), preview any version live, see what changed, and restore it. Recent changes after the restore point stay in the chat and can be reapplied anytime, so restoring is never a dead end.
  • Restore points and pinning. Pin versions you consider good, so a known-safe state is always one click away.

Reverts cover your app's code and design. If the data in your database is what went wrong, the Data panel's History view can roll it back too, and an undo point is saved automatically before every restore. See Database.

When a change went sideways​

If a big request came back wrong, resist the urge to patch it with more prompts. Layering corrections on a bad result usually compounds the mess. Instead, revert to the last good version, then re-prompt in smaller steps, one focused change per message, checking the preview between each. See Best practices for how to phrase those smaller asks. Downvoting the bad response also helps: Roc learns from downvotes and reverts within your project.

Credit questions​

A few billing facts explain most confusion during troubleshooting:

  • Starting a chat build requires a minimum balance of 2 credits. If you are below that, top up or wait for your monthly renewal. See Credits.
  • Build-error auto-fixes are always free, and runtime error fixes run at a reduced rate.
  • Publishing never costs credits.

If you hit the "Insufficient AI Credits" dialog mid-session, your work so far is safe; add credits and continue.

Missing data and 403 responses​

If your app shows an empty list, or you see a 403 in your data, that is usually not a bug. Tables in your app's database have visibility rules, and a 403 means table visibility is doing its job: an anonymous visitor asked for data that only signed-in users (or only the row's owner) may read. Sign in as the right user and the data appears. If you want the data to be public, ask Roc to change the table's visibility. The full model is explained in Security rules.

Getting help​

If none of this resolves your issue, email [email protected] with your project name and a description of what you expected versus what happened. Screenshots of the error badge or the chat exchange speed things up considerably.