Describe the whole problem first
Whatever the source of the code, check it in the conditions where it actually runs. AI can help investigate, but it needs specific evidence.
For example, quantity 10, unit price 12 and delivery 8 give 128 locally, but the online Calculate button produces no result. Record the online address, browser, steps, time and page message, and save the current version. Remove keys and personal information from error screenshots and logs before sharing them.
Step 1: repeat the same steps
See whether the problem happens consistently. Open a new browser window and enter the same values. If accounts are involved, record the test account's role without sharing its credentials.
Find the first difference: does the page fail to open, the button do nothing, the request fail, or a successful request return the wrong result? Each points to a different place to investigate.
Step 2: narrow the search using the symptom
| Symptom | What to check first |
|---|---|
| The home page works, but refreshing another address fails | Page routing and hosting configuration |
| Content appears, but clicking produces no result | Browser errors, request status and the button logic |
| A request works locally but fails online | Production API address, environment settings and access conditions |
| Saved data disappears when reopened | Whether it was written and how production storage is configured |
| Different accounts see the same records | Server-side login identity and the scope of data queries |
These are investigation directions, not confirmed causes. The browser console and network panel show page errors and request status. If there is a backend, check the server logs for the corresponding time too.
Step 3: compare local and online conditions
Ask AI to list the dependencies, start commands, configuration names, APIs and data sources used by this project. Compare them with production. Check whether settings exist and have the right format; do not paste secrets into the conversation.
Review recent changes. Address one evidence-backed cause at a time and retain the change record. If the online problem disrupts use, you may restore a known working version and investigate in a copy. Before changing data, confirm the backup and recovery approach.
Step 4: retest the original input after a fix
An error disappearing is not enough. Repeat the initial steps and compare the actual result with the expected result. Then test related behaviour: different inputs, a page refresh and a failure message. Use different identities if accounts are involved.
If another account's records are accessible, check every related data entry point. The fictional teaching example shows how to plan such checks; it is not a production system that has passed real tests.
Keep a troubleshooting note
Record the symptom, confirmed cause, change, retest result and remaining work. You can return to it when upgrading, migrating or adding a feature. Use the pre-launch checklist for the broader publishing checks.
Questions
Why does it work locally but fail online?
Should I paste the error into AI and ask it to rewrite everything?
What if an account can see someone else’s records?
Read next
- From an idea to a usable tool — Connect action, checking and version records
- Pre-launch checklist — Add the checks your project needs
- Fictional client-record example — See how identity and data scope fit together
