Logs and monitoring

Once your app is live, you want to know what it is doing — and to hand Vorx exactly what it needs to fix an issue.

What you can see today

Scheduled job runs. Open Settings → Cloud → Jobs and open a job's run history. Every execution is there with its status and timing, and a failed run shows the error. This is the surface to use when a scheduled job "didn't work".

That is the whole of it for now. There is no request log, no per-function run log, and no error feed for your live app.

What is not built yet

Request logs, backend function run history, and integration call logs are on the roadmap and are not available today. If you have been sent here expecting them, that is our documentation's fault rather than a setting you have missed — this page previously described them as though they existed.

From symptom to fix

Without a log to read, the loop that works is the one that hands Vorx the error itself:

1. Reproduce the problem in the app.
2. Copy the error the app shows you — the on-screen message, or the browser console for a client-side failure.
3. Paste it into chat with what you expected to happen.
4. Confirm the fix in the preview, then publish.

Vorx reads a real error and patches the cause, rather than guessing from a description of the symptom. For a scheduled job, take the error from its run history first.

Did it even run?

When an automation "doesn't work", the first useful question is whether it fired at all — and for scheduled jobs you can answer it: a job with no runs has a scheduling problem, a job with failed runs has a code or credentials problem. Its run history separates those two cases in seconds.

Next steps

• Fixing errors — turning an error into a fix
• Scheduled jobs — cadence, and watching the first run
• Backend functions — what runs on the server