Before you start
You need permission for each view you inspect. Identify the affected resource and approximate time without assuming that a temporary loading state means data was lost.
What to do
- Open Operations and identify the intended action by its time, initiator and result. Distinguish running or pending work from completed, failed or interrupted work.
- Use View output to inspect the result. Expand original details when offered and retain the relevant operation reference before considering another attempt.
- Open Monitoring to compare current resource measurements with the displayed history. Check the covered time range and whether the view is still collecting data.
- Use System logs for recent host journal information when your role permits. Use Audit trail to check the actor, action, target, time and recorded outcome; it is separate from an application's own transaction history.
- After an operation, verify the affected resource in its own view or ordinary application. Share only the relevant reference, time and redacted error with the infrastructure administrator if help is needed.
What happens next
You have evidence about the selected action and resource state. Neither a graph, an audit entry nor an accepted action request alone proves the desired application outcome.
If something goes wrong
Refresh the relevant view and check its actual time range before diagnosing missing information. A response timeout does not establish that work stopped; inspect its current operation and target state before retrying. Keep customer records, tokens, private addresses and unrelated log contents out of public reports.
