Logs
The POS has two log interfaces: the in-app activity log (inside the POS application) and the WP Admin Logs page (inside WordPress). Together they give you a complete picture of POS activity for debugging and auditing.
POS Application Logs
From v1.10.0, the in-app log lives in Store health → Logs (the heartbeat icon in the navigation drawer — the standalone Logs screen it replaces was removed). This section describes the v1.10.0 log; see Store Health for the full tour of that area.
Accessing Logs
Open Store health from the left navigation drawer (the heartbeat icon) and select the Logs tab.
Interface Overview
The log is a ledger of activity on this device, kept for 30 days. Each row shows:
| Column | Description |
|---|---|
| Time | When the event occurred |
| Level | Severity — error, warning, action, sync, or info |
| Event | Human-readable description (translated at display time) |
| Took | How long the operation took |
| Status | The outcome |
Above the ledger, a status line shows the sync heartbeat — when the last change check ran and when the next is due — and a stat header counts today's events and errors, stuck records, and changes waiting to send. Most of these are tappable filters.
Filtering
Preset chips filter the ledger: All, Actions (things a person did — sales, edits, settings changes), Errors, and Sync. A separate Verbose diagnostics toggle captures extra detail for 24 hours, then switches itself off automatically.
Row Details and Error Codes
Tap an error or warning row to expand it. The detail view gives you:
- What happened, in plain language
- Your data — an explicit data-safety statement (for example, whether the change is safe on the server or exists only on this device)
- What to do — the recommended next step
- A help link — errors carry a code (e.g.
SYNC121,AUTH311) linking to the Error Codes documentation - A copyable event code — row titles are translated at display time, so the event code is the stable identifier. Quote it when contacting support.
WP Admin Logs Page
The POS plugin also provides a server-side Logs page in the WordPress admin area. This page shows POS-specific warnings and errors logged on the server, which can help diagnose issues that may not appear in the POS application itself.
Accessing the WP Admin Logs Page
Navigate to WP Admin > POS > Settings, then select the Tools tab and click Logs.
Unread Badge
The Logs menu item displays a badge indicating unread log entries:
- Red badge - There are unread error-level entries
- Amber badge - There are unread warning-level entries (but no errors)
Visiting the Logs page resets the unread counts. The counts are tracked per-user, so each admin sees their own unread status.
Filtering Entries
Use the level filter to narrow down log entries:
- All - Show all log entries
- Errors - Show only error-level entries
- Warnings - Show only warning-level entries
Expandable Entries
Long log messages are truncated at approximately 100 characters. Click on an entry to expand it and see the full message along with any additional context data.
Pagination
Log entries are paginated server-side. Use the pagination controls to navigate through older entries.
Fatal Errors Banner
If the server has fatal-errors-*.log files, the Logs page displays a warning banner at the top. This banner links to WooCommerce > Status > Logs where you can view the full fatal error logs. Fatal errors are typically PHP-level crashes that prevent the POS API from responding.
Using Logs for Support
When requesting support:
- Reproduce the issue - Perform the action that causes the problem
- Check the logs - Look for errors or warnings in Store health → Logs
- Expand the row - Read the data-safety line and suggested next step
- Copy the event code - Include it in your support request; it's the stable identifier for what happened
- Turn on Verbose diagnostics if support asks for more detail — it captures extra information for 24 hours
Performance Monitoring
Aggregate performance lives in Store health → Performance: requests, data transferred (a lower bound when responses omit their size), and typical response time over the last 24 hours, plus an hourly uptime strip. If response times look high, see Server Performance.