Skip to main content
Resources & navigation
Business settings & access

Review integration boundaries and system health

Last updated 2026-08-062 min read

Identify the module that owns each connection and use the manager health summary without mistaking it for live telemetry.

On this page

The Integration control center explains which Ellich module owns each connection. System health provides a manager-facing readiness summary and links to the operational screen that contains the real detail.

Review integration ownership

Open Admin → Settings & Integrations → Integrations.

  • Native POS runtime owns selling, tables, active orders, and payments.
  • POS settings, Printing and receipts, and Hardware own checkout policy and device behavior.
  • POS mappings, catalog readiness, and Inventory own product availability, recipes, counts, procurement, and food cost.
  • Site Builder owns pages, domains, commerce links, and website publishing.
  • The legacy external POS bridge is intentionally disabled and is not part of the current runtime.

Do not troubleshoot a native Ellich order by searching for a disabled legacy connector. Open the module that owns the failed action.

Use System health correctly

Open Settings & Integrations → System health. Review the Runtime, Devices, Reports, Database, and Risk lanes, then follow the module link for evidence:

  • POS hardware for registers, printers, stations, receipt routing, and device trust.
  • Kiosk devices for enrollment, heartbeat, placement, and table binding.
  • Print jobs for queued, sent, and failed print work.
  • Reporting hub for report data.
  • Scheduled reports for recurring email configuration.
  • Integrations for connection ownership and boundaries.

The current System health page is intentionally a lightweight manager summary; it is not a live developer telemetry console. A percentage or posture card should direct the investigation, not be treated as final proof of a service outage or recovery.

Verify readiness before service

  1. Confirm POS and required customer-facing surfaces open for the correct store.
  2. Verify active devices and heartbeats in their owning modules.
  3. Run a printer test and confirm physical output where printing is required.
  4. Confirm the Reporting hub loads current business data.
  5. Review scheduled report state if leadership delivery is time-sensitive.
  6. Review Site Builder domain and publish readiness when the public site changed.

Escalate with useful evidence

Record the affected store, module, action, exact time, user role, device or job ID, current status, and the last known successful test. Do not include passwords, POS PINs, API keys, cookies, card data, or database URLs.