Debug with logs and file history

Use execution output to understand what happened and file history to identify which source changed. These answer different questions. A previous source version cannot undo a contact update, outbound request, or other side effect from a run.

Start by identifying the app, group, environment, and whether the failure occurred in a draft simulation or a published invocation.

In the simulator, separate Validate app, Build app, and execution. Validation failures are not network errors, and a successful build does not mean the function ran.

Each diagnostic can include a file and line link. Open that location and compare it with the saved source, not an unsaved editor draft. For example, a Form field named reference appears directly as result.reference; a validation error about result.data is a wrong argument shape, not a missing API permission.

For a widget, inspect the action name, arguments, and returned result as well as the React interface. If the interface loads but no action entry appears, check the client handler. If the action starts and fails, investigate its server implementation.

Open Logs in the app's own navigation. Keep it distinct from the developer area's top-level API Logs tab. App logs concern app runs; API request logs concern REST requests.

Simulation output stays in the simulator and does not create persisted app-log entries. An unpublished app can therefore show No app logs even after successful simulations. Use the simulator's output for draft tests and the app log list for normal runtime executions.

Use the run time, group, success or failure, and runtime details to find the relevant invocation. Compare the log with the published version and the input that triggered it. A user reporting a failure from an old published widget may not be running the draft you just simulated.

Log identifiers, counts, branch choices, and completion outcomes when they help diagnose a run. Avoid logging entire contacts, form submissions, API keys, secret values, or raw responses containing private data. Simulation's API diagnostics can already include request parameters, so inspect them before adding more logging.

The app Overview and simulation results expose CPU/runtime and memory usage. Use them to identify a change from the app's normal behavior. A long wall-clock duration can involve waiting for a network service; a high CPU or memory figure points to a different class of problem.

Check bounded pagination, repeated calls, large intermediate arrays, and retry loops before increasing limits. If a timeout occurs after a write was sent, read back the intended result before replaying the operation. A failure at the end of a run does not establish that nothing happened.

Open Edit, select the relevant file, and choose History. The File history view lists saved versions and shows a comparison with the selected version. Published markers help relate source history to released bundles.

History is scoped to the file, group, and client/server project. A widget's server index.ts and client index.tsx have separate histories. Select the correct project before comparing a similarly named file.

Look for the smallest change that explains the failure: an export rename, changed field key, different API parameter, removed validation, or altered return shape. A visible diff is evidence of a source change, not proof that the published app already includes it.

Use the history view's revert action for the selected version. Resolve unsaved changes first; reverting is disabled while the file has unsaved edits. The operation writes the selected content back into the draft and records a new history entry.

Reverting one file does not restore every group, form definition, access setting, secret, or external data change to the same point in time. Check related files and configuration before treating it as a complete rollback.

Simulate the restored draft, then publish an update if it is the version you want visitors or triggers to run. Merely reverting a draft file does not change the currently published bundle.

Record the environment, app/group, published version or draft state, failing stage, error message, and a minimal synthetic input. Include the source location and expected outcome. Remove credentials and personal data from anything shared outside the authorized team.

After fixing the issue, rerun the failing case and a normal case. For an API-backed action, also verify the final record state. Keep the test in your internal verification record so a future editor change does not reintroduce the same failure.