Troubleshoot an App

The goal of troubleshooting is not to make an error disappear temporarily. It is to locate the affected layer and identify a cause that can be tested. Record the behavior and environment before changing the configuration, and test one possible cause at a time.

Define the issue

Turn a vague symptom into a reproducible issue. Record at least:

• Expected result: What should happen.
• Actual result: What appears on the page, including errors or incorrect data.
• Reproduction steps: The page where you start and each action you take.
• Scope: Whether it affects every user and record or only specific ones.
• Environment: Browser, device, viewport, and account state.
• Incident time: Used later to locate the request and runtime logs.
• Recent changes: What changed before the issue appeared and whether those changes were synced or published.

Reduce the reproduction path where possible. Instead of “orders do not work,” record “a signed-in customer selects Confirm receipt on the order details page; the button starts loading, but the order status does not change.”

Isolate the failure

Follow one operation from front to back:

1. Confirm that the editor configuration is valid.
2. Confirm that the page renders and responds to the interaction.
3. Confirm what the frontend sends and what the server returns.
4. Inspect how the request runs in the backend.
5. Confirm that the page uses the returned result correctly.

Once you find the first point that differs from the expected behavior, investigate that point instead of opening every debugging tool at once.

Inspect the editor configuration

The error icon in the upper-right corner of the editor shows the number of configuration errors. Select an error to open the related configuration. Resolve errors the editor already detects before running the app again.

Check whether:

• Parameter and binding types match.
• Required settings have values.
• Data source, page parameter, and component references are still valid.
• Actions and Actionflow nodes have all required inputs.
• Conditions cover every data case and include the recommended fallback branch.

For specific messages, see the Error Reference.

Inspect the page and interaction

If the page does not render as expected, or the interaction produces no request, check whether:

• The component is visible and interactive.
• The trigger is attached to the correct component and event.
• The conditional view selects the expected branch.
• Page data sources, page parameters, and client variables contain the expected values.
• Components use the intended absolute or relative positioning.
• The parent size, direction, alignment, and overflow settings are correct.

Use Elements to inspect rendered sizes and styles, and Console to find frontend errors. If the interaction produces no request, the issue is usually still in the page configuration, trigger, or frontend action.

Inspect the network request

After confirming that the interaction should send a request, press F12, or right-click and select Inspect, then open Network. Clear existing entries, reproduce the issue once, and select the relevant request.

Answer three questions in order:

1. Was the request sent? If not, return to the page trigger and action configuration.
2. Was the request correct? Compare the Request Payload parameters, types, and values with the editor bindings.
3. What did the server return? Inspect the HTTP status, response data, and any details in errors.

If the response contains a clear error, look it up in the Error Reference. If the request reached the backend but produced the wrong result, continue with runtime logs.

Inspect backend execution

For requests involving Actionflows, database operations, APIs, AI Agents, or triggers, choose the relevant category in Runtime Logs. Narrow the results using the incident time and known fields.

Check whether:

• The Actionflow or trigger started.
• Execution stopped at a particular node.
• Node inputs and outputs match the expected values.
• A database operation, API, or AI Agent returned an error.
• Entries with the same traceId form a complete execution path.

Once you find a related entry, copy its traceId, find other entries from the same request, and review their inputs, outputs, status, and errors in chronological order. See View Runtime Logs for categories, query syntax, and the complete tracing workflow.

Inspect real-time updates

If a real-time data source does not update, check in this order:

1. Confirm that the underlying data changed.
2. Confirm that the data source uses a real-time subscription rather than a standard query.
3. Select WS in Network, then refresh or reopen the relevant page.
4. Confirm that a persistent WebSocket request is present.
5. Open Messages and watch for new data or errors when the underlying data changes.
6. If no message arrives, review the data source filters and current user’s permissions.
7. If data arrives but the page does not update, inspect the component binding and conditions.

Base the diagnosis on the connection state and messages visible in the browser. An internal connection name or heartbeat message alone does not establish the root cause.

Verify the fix

Use the evidence you collected to state one testable hypothesis, such as “the request parameter is empty because the page parameter was not passed,” and make the smallest relevant change.

1. Change only one possible cause at a time.
2. Repeat the test with the same account, data, and steps.
3. Confirm that the original error is gone and that the page, request, and backend result are all correct.
4. Test adjacent cases, such as other roles, empty data, and boundary values.
5. Make sure the test environment uses the latest configuration: use Sync Changes or Publish after backend changes, and Publish after frontend page changes.

If the result does not change, revert changes based on the failed hypothesis, keep the new evidence, and test the next possible cause. The absence of a visible error does not by itself prove that the issue is fixed.

Get further help

Use the AI assistant

After collecting the symptom, error, or traceId, open the AI assistant in the editor and provide:

• The expected result, actual result, and reproduction steps.
• The incident time and environment.
• The project ID and relevant page or component ID.
• What you already investigated.
• The error message or traceId.

The AI assistant can read the related logs and help analyze the issue. If the evidence points to a platform defect, you can submit the defect through the assistant. Review the generated reproduction details and remove sensitive information before submitting.

Report a reproducible issue

If you still cannot isolate the cause, provide support with:

1. Expected result: What should happen.
2. Actual result: What appears on the page and the exact error message.
3. Reproduction steps: The page where you start and each action you take.
4. Environment: Browser, device, viewport, and account state.
5. Location: Project ID, page or component ID, and incident time.
6. Troubleshooting performed: What you already inspected or changed.
7. Evidence: Redacted screenshots, request data, logs, and traceId.

Submit the issue through the Momen forum  or email hello@momen.app. The report should give another person enough information to reproduce the issue instead of only stating that the page or request failed.