Current service health. No decorative uptime theatre.
This page runs a live, uncached check against the Porosi core API and primary database, then explains which ordering surfaces depend on that core.
- API
- Checking
- Database
- Checking
- Probe
- —
One direct probe. Every dependency labelled honestly.
The API and database states come directly from the live health response. Ordering surfaces are shown as dependent services; integration outcomes remain connector-specific.
Authentication, tenant requests and order operations reach Porosi through this service.
Customer accounts, products, prices, orders and operational records depend on it.
Supplier-branded portals depend on the reachable core API and database.
Order review, products, customers, fulfilment and finance controls use the core platform.
Supplier-specific customer apps use the same account, catalogue and ordering API.
Connector permissions, mappings and partner responses are assessed on each sync result.
A green core check is useful. It is not a promise about every screen.
It proves that this browser reached the public health endpoint and that the endpoint reported both the API and database as healthy at that moment.
- 01PROVESCore endpoint reachable
The public API returned a valid response.
- 02PROVESDatabase check passed
The response explicitly reported database health.
- 03DOES NOT PROVEEvery tenant-specific path
Account configuration, permissions and local device state can still affect one workflow.
- 04DOES NOT PROVEEvery partner connector
Xero and other systems return their own validation and availability results.
This is a current health check, not a retained availability report. Historical uptime will only appear when it is backed by a durable measurement record.
No active platform-wide incident notice is posted.
If the live core check is healthy but your tenant, account or integration is not behaving normally, treat it as a workflow-specific support issue and send the context below.
Send the evidence that identifies the failing path.
A screenshot alone can hide the important context. Include the supplier, surface, account and exact action so support can follow the same route.
- 01Supplier tenant
The supplier name and the Porosi domain being used.
- 02Affected surface
Web ordering, iOS, Android, supplier dashboard, API or integration.
- 03Account or order
The customer account and order reference, if one exists.
- 04Exact time and action
What was clicked, what was expected and what appeared instead.
- 05Visible request reference
Include any request ID, validation result or sync error shown.
Read the signal at the right level.
Does a healthy core check mean my Xero sync succeeded?
No. The health endpoint checks Porosi’s API and database. A Xero sync also depends on connector authorisation, mappings, the source order and Xero’s response.
Why can one customer still have a problem?
A customer-specific issue can come from account access, catalogue visibility, delivery rules, permissions or device state even when the shared core is reachable.
Does this page publish historical uptime?
Not currently. It deliberately reports the current live probe without presenting an unsupported historical percentage.
What happens if the live check cannot run?
The page says it could not verify the service from this browser. That is not automatically labelled as an outage because a local network or browser policy can also block the request.