Operate

Check operations, logs, and audit records

Follow one failed or waiting item from Operations into logs and audit records.

Your progress

Follow this journey

0 steps complete
0%

Progress is saved only in this browser.

Before you start

Record what the person was trying to do. Record the tenant, time, item, message, and request or run ID.

Do not collect passwords, tokens, private keys, or customer documents that are not needed for the check.

Find the work in Operations

  1. Open System operations for the whole installation or Tenant operations for one tenant.
  2. Choose the smallest useful time range or work group.
  3. Find the active, waiting, or failed item.
  4. Record its service, state, item ID, job ID, run ID, or request ID.
  5. Read the message before you change anything.
The Tenant operations page used to find waiting or failed work
Start with the tenant, state, and one useful ID. Earlier development interface, captured 22 August 2026. Follow the current text for RC1. Open the full image.

Follow the item into the logs

  1. Open Operational logs.
  2. Use a short time range around the failure.
  3. Enter the tenant and the best available ID.
  4. Read the events in time order.
  5. Find the first event that explains the failure.
  6. Record the service and message.
Operational log results for recent requests
Read the earliest useful message before later retry messages. Earlier development interface, captured 22 August 2026. Follow the current text for RC1. Open the full image.

Check for an administration change

Open Audit history when the problem may follow a change to access, settings, a Connection, a model, or another managed item.

  1. Use the same tenant and time range.
  2. Filter by person, action, resource, or request ID.
  3. Check the result of the change.
  4. Compare its time with the first failure.
Tenant audit history with administration changes
Audit history shows who changed an important item and whether the action succeeded. Earlier development interface, captured 22 August 2026. Follow the current text for RC1. Open the full image.

Choose the next action

  • Fix a setting only when the evidence identifies that setting.
  • Restore access only after Check access confirms the missing action.
  • Test a failed Connection before a workflow uses it again.
  • Restart a service only when its state or logs show that a restart is needed.
  • Retry work only when the operation is safe to repeat.

Check the result

Return to Operations after the change. Confirm that the service is ready and that new work reaches a final state.

Keep the original IDs and the change record when your organisation needs evidence of the investigation.

If the cause is still not clear

Keep the current evidence. Record the exact version, time range, service, tenant, IDs, and messages.

Do not make several unrelated changes at once. Each change makes the original cause harder to find.

Next step

Read Use the Operations pages and Use logs and audit records for more detail.

Pūnaha Docs

Search the guides

Enter at least two characters.

    Product screen

    View the full screenshot