Reference

Fix service readiness and storage problems

Understand a running service that is not ready or data that is unavailable after a storage change.

Start with what you see

Choose the closest problem

Select one symptom. You will still check the evidence before changing anything.

What you see

  • /health/live succeeds but /health/ready does not.
  • A service does not appear as ready in System operations.
  • Documents, knowledge indexes, or logs are unavailable.
  • Old knowledge seems missing after a storage destination changed.
The System operations Servers view
An online server still needs its required services and data stores before it is ready for work. Earlier development interface, captured 22 August 2026. Follow the current text for RC1. Open the full image.

What it means

Live means the program is running. Ready means it can receive its normal work.

Changing a storage destination does not move old data. The old data remains at its earlier destination until an approved move or rebuild is complete.

Likely causes

  • A required Control, Workflow, or AI database is unavailable or needs an update.
  • A Workflow server has no local AI service and cannot reach its private AI address.
  • A service setting, private network route, or internal authentication value does not match.
  • The configured storage path, bucket, container, permission, or key is wrong.
  • Several servers use local storage instead of one approved shared destination.
  • The storage setting changed before old data was moved or rebuilt.

Safe checks

  1. Check Live and Ready separately on the affected service.
  2. Read the service state in System operations.
  3. Check the first readiness message in the service logs.
  4. Confirm the expected service role and required database are reachable.
  5. For Workflow, confirm that local AI is present or the approved private AI address is set.
  6. Compare the configured storage destination with the approved design.
  7. Confirm that every server which needs shared data uses the same durable destination.

Solutions

  • Restore the required database, service, or private route before returning the server to traffic.
  • Run an approved database update once before starting the updated service group.
  • Correct only the identified storage setting or permission.
  • Keep an unready server out of the load balancer.
  • Move existing data or rebuild knowledge from approved source documents before switching storage.
  • Do not silently use local storage when shared storage is required.

What to collect

Collect the product version, service role, server name, Live and Ready results, time, safe destination name, database version, request ID, and visible message.

Do not collect database passwords, storage keys, internal service tokens, private network details that are not needed, or customer files.

Read Check service health, Run Pūnaha on several servers, and Plan storage and backups.

Pūnaha Docs

Search the guides

Enter at least two characters.

    Product screen

    View the full screenshot