User, System, Channel & Request Logs

Settings > System Settings holds four separate records of what has happened in Helm WMS: User Logs, System Logs, Channel Logs and Request Logs. This article covers which one answers which question, how to find a single entry, and how long entries are kept.

Which Log Should I Look In?

They look similar and answer very different questions, so picking the right one is most of the work. Each is a read-only list, newest first, with its own tile under System Settings.

Log	What It Answers	What Writes To It
User Logs	Which person did this, and when.	Anything a signed-in user did, in the browser or the mobile app.
System Logs	What happened with nobody behind it.	Background jobs and scheduled tasks.
Channel Logs	Did my stock reach the sales channel.	Stock sync and product updates between Helm and your channels.
Request Logs	What was sent, and what came back.	Requests into Helm from the browser, the apps, the public API, webhooks and integrations.

Stock Logs is not one of these. It lives on the product record, as the Stock Logs link under Stock Control, and has its own article. If the question is why a stock figure changed, none of these four pages will answer it.

Example scenario: a courier label failed to generate this morning. Request Logs holds the request Helm sent the courier, with the payload and the error that came back, and the shipment links straight to it. User Logs would only tell you who pressed the button.

One kind of entry has no page at all: activity against Helm's own API, and the calls Helm makes out to couriers and sales channels. Those go to a separate group none of the four lists reads from, so hunting for the call Helm made to a channel comes up empty on all four.

Before You Start

Every log opens on a narrow date range. User Logs, System Logs and Channel Logs open showing today only; Request Logs looks back 30 days. Widen the date filter before you conclude that something was never logged.
Entries are written after the event, not during it. User Logs, System Logs and Request Logs are all fed by background work, so an action from a few seconds ago may not be listed yet.
You need log permissions. Log Listing opens the lists and Log Detail opens a single entry. Channel Logs and Request Logs sit behind their own separate permissions, which is why one person sees all four pages and a colleague only two.
Nothing here is a permanent archive. Request Logs is cleared a whole month at a time rather than a day at a time, so an entry lives between roughly 60 days and four months depending on where in the month it falls. User Logs and System Logs have their own clean-up task. Copy out anything you need for a dispute the same day.
You cannot ask for more than a year back. On User Logs and System Logs, a start date older than 12 months is rejected.
The pages are read-only, and there is no export. Nothing edits, deletes or downloads an entry, so what you take away is the reference number and whatever you copy out yourself.

How to Find an Entry in Helm

All four share the same header controls, so the routine is the same wherever you land.

Go to Settings > System Settings and open the log you need.
Set the date range first. Open Filters, use the date filter, then Apply.
1. Pick a preset down the left: Today, Yesterday, This Week, Last Week, This Month, Last Month or Last 3 Months.
2. Or choose Custom, which clears the selection so you can click a start and end date on the calendar.
3. The From and To rows beneath the calendar set the time of day at each end.
Narrow further with the filters that page offers, listed below.
Use the search box for something specific. It filters the list and also offers a suggestion list you can click to open one entry. What it searches differs per log, the biggest single cause of an unexpectedly empty list.
Click a column heading to sort, and again to reverse. This works on User Logs, System Logs and Request Logs on every column except Event and Correlation ID; Channel Logs cannot be sorted.
Click a row to open the entry. All four detail pages include the raw record.
Save a combination you use often. Under Saved Filters, choose Save as New and name it; Clear All Filters resets the list.
Set the columns in the View Manager with Add or Remove Columns and Drag to Arrange Columns. Reset to Default puts them back; Save keeps your layout.

User Logs & System Logs

These two are one log split in half. If a signed-in user was recorded against an event it goes to User Logs; if not, to System Logs. That explains an action you expected under your own name sitting in System Logs: a background job or scheduled task completed it. The split is not quite exhaustive, because of the group above that has no page.

Both pages show the same columns.

Column	What it tells you
User	Who did it. On System Logs this reads System.
Type	The kind of event, such as Login or User Created.
Event	The event as a sentence: the person, the record and what changed. This is the column you read.
Reference	The entry's own reference. Click to copy it, and quote it when you raise a query.
IP Address	The address the action came from.
Date & Time	When it happened.

User Logs filters on Date & Time, IP Address, Type and User; System Logs on Date & Time and Type only, with a shorter fixed Type list, so the two pages offer different options under the same filter name.

The search box on both matches the user's name, the Type, the text of the Event and the address the request went to. A surname, a phrase such as created, a full IP address or an order number all work: Helm rebuilds the event sentence with the order number filled in before matching.

Opening an entry shows the request and response Helm recorded at the time, alongside the User, IP Address and User Agent. Cookies and the cross-site request token are left out; nothing else is masked, so read what is there before you pass it on.

Channel Logs

Channel Logs is the conversation between Helm and your sales channels about stock and product records. It is deliberately narrow, covering five kinds of event: a channel product being updated, stock being uploaded, sent or synced, and a stock sync failing. An order arriving, for instance, is not here.

The columns are Date, Status, Log Type and Message. Log Type names the event; Message carries the text the channel sent back, which is where the real reason for a failure sits. Status is one of WAITING, IN PROGRESS, SUCCEED, WARNING, FAILED or INFO, set by the channel service rather than by Helm, so read the Message rather than the status alone.

There are two filters, Date and Status. A third, Channel Product ID, stays hidden until it already has a value, so you only see it if you arrived from a product. The search box also differs: it looks for one channel product by code or name, so a search matching no product returns an empty page rather than a partial match.

The quickest route in is from the product. On a product's channel list, the See Stock Logs action opens Channel Logs filtered to that channel product. The name is misleading: it shows channel activity, not warehouse stock.

These entries are held by the channel service rather than in your own Helm data, so an unusually empty list is worth a second look before you treat it as proof nothing ran.

Request Logs

Request Logs is the technical one, and the log support will ask you for. It records what was sent, what came back, how long it took and which platform it came from, and it is the only log that shows the payload.

It is not quite everything. A request is only recorded when Helm can tell which company it belongs to, so traffic with no company attached, signing in being the clearest case, is not logged at all. Health-check addresses and the internal queue dashboard are excluded outright.

Above the list sit four quick filters with live counts: 2xx Success, 4xx Client Error, 5xx Server Error and Empty Response. Clicking one applies it, clicking again clears it. Starting with 5xx Server Error is usually the fastest way in.

Column	What it tells you
Date	When the request was handled.
Status	The response code, coloured by range.
Method	GET to read, POST, PUT, PATCH or DELETE to change something.
URI	The address that was called.
Platform	Frontend, Public API, Mobile App, Desktop App, Webhook, Integration or System.
User	Who it was made as, or System where no user was attached.
Time (ms)	How long Helm took to answer.
Response	OK, FAILED or EMPTY. EMPTY means only that the response carried no content: Helm checks that before success, so a failure that returned nothing also reads EMPTY. Read it with Status.
Correlation ID	The thread tying related requests together. Click it to see the rest.

The filters are Date & Time, Method, User, Platform, Status Code, URI, Route Name, Correlation ID, Response Success and Response Empty. Status Code is a range, not a single value: choose Greater Than, Less Than, Between or Is, then fill in the boxes. The search box matches part of the URI, so typing shipments finds every shipment call.

Opening an entry gives you four panels, Request Headers, Request Body, Response Headers and Response Body, each with a Copy button, and four cards: Request Info, Client Info, Response Info and Identifiers. Between them they carry the Route Name, Execution Time, Auth Type, Request Size, Response Size, Request ID, Correlation ID and App Slug.

Auth Type separates a person from a machine, usually the first thing support will ask. It is not a filter, so open an entry to read it.

Auth Type	What made the request
Sanctum Session	A signed-in user in the browser.
Personal Access Token	An API token, public API or app.
App Store Token	An installed app, which also fills in App Slug.
Channel Webhook	A sales channel pushed it in.
Shipping Webhook	A courier pushed it in.
Integration Token	An integration.
None	Helm could not identify the caller.

Check the payload before you pass it on. Helm masks a named list of keys, the authorisation and cookie headers plus fields such as password, token, secret and card number, but only in the request headers, the request body and the response headers. The Response Body is stored exactly as Helm sent it, and the entries Helm writes for its own courier, notification and import calls are not masked at all.

You will often arrive from somewhere else rather than from Settings: a failed job in the Jobs Queue offers See Logs, a shipment offers View Shipment Request, and notification history offers View Log. Follow those links rather than searching, because Helm records its own outbound courier, notification and import activity here too, and those entries have nothing in the URI column and are logged against System, so the search box will never find them.

Entries are written once Helm has answered, so a request made seconds ago may not be there yet. From the Jobs Queue or a shipment, Helm sends you back with Log not available yet; from notification history you get a plain error page, which means the same thing. Wait and try again.

Best Practices & Notes

Follow One Action With Correlation ID

A single action in Helm often makes several requests. When one fails, open it and click its Correlation ID to pull up the rest of the sequence in order, turning a bare error code into the story of what was attempted.

Sort by the Column That Answers the Question

When the complaint is slowness rather than failure, sort Request Logs by Time (ms) and read from the top rather than guessing a threshold to filter on. Sorting by Status groups the failures together.

FAQ

Why Is the List Empty?

Almost always the date range. User Logs, System Logs and Channel Logs open on today, so anything from yesterday is out of view until you widen the filter. On Channel Logs, a search matching no channel product also returns an empty page.

Why Does the User Column Say System?

No signed-in user was recorded against the entry: a background job or scheduled task did the work. Integration and API activity is a different case, going to the group with no page, so it does not appear here at all.

Can I Export a Log?

No. There is no export action on any of the four pages. Copy the parts of an entry you need, or take a screenshot.

How Long Are Entries Kept?

Request Logs is cleared a month at a time against a 90-day setting, leaving an entry alive for between roughly 60 days and four months. User Logs and System Logs have their own clean-up task, and Channel Logs is held by the channel service.

If you have found the entry and still cannot explain what happened, contact support with the Reference from User Logs or System Logs, or the Correlation ID from Request Logs.

Was this helpful?

Still need help? Share an idea