Fixing errors

Things occasionally break — a page that won't load, a button that does nothing, data that doesn't save. Fixing them is the same conversation as building.

Describe what you see

Tell Vorx what's wrong in plain terms: "the dashboard is blank," "saving a task throws an error," "the login button doesn't do anything." You don't need to know the cause — what you observed is enough to go on.

The three things worth including every time:

1. Where — which page or screen.
2. What you did — the click or the form submit just before it broke.
3. What happened — blank, an error message, the wrong data, nothing at all.

"After I submit the new-order form, the page errors" is a fast fix. "It's broken" is a slow one.

Vorx catches a lot before you do

Most builds are checked before they reach you: Vorx renders the app in a headless browser and clicks through the main flows, fixing errors it finds so the version you see already works. What reaches you is the exception, not the rule.

Use the logs

For anything server-side — a backend function, a scheduled job, an integration call — take the error itself — a scheduled job's failed run is in Settings → Cloud → Jobs; anything else has no run log yet (logs and monitoring). Pasting the error straight into a prompt is often the fastest route to a fix, because it hands Vorx the cause rather than the symptom.

Roll back if a fix goes sideways

If an attempted fix makes things worse, roll back to the last good checkpoint and describe the problem again. You never have to dig your way out — you can always return to a working state, and a revert costs nothing.

When it's setup, not code

Some breakages aren't bugs. Before asking for a fix, check:

• An integration key is set, and set for the environment you're testing — see Secrets.
• Social sign-in is being tested on your published URL, not the preview — see Social login.
• A build actually finished; the preview only updates when a run completes.

Still stuck?

See Troubleshooting for the issues that come up most, or reach the team from the support page.

Next steps

• Troubleshooting — the usual suspects
• Logs and monitoring — reading what the server saw
• Version history — getting back to working