Logs
Follow live and historical runs, filter technical events, and retain diagnostic evidence for investigation and support.
What are Logs used for?
Logs is the technical timeline for one sales channel. It records the loaded configuration, selected products, rules, manipulations, processing steps, warnings, and failures. Use Results for the business outcome and Logs to understand why it occurred.
Live log, runs, and sessions
During a run, new entries and progress appear without a page reload. Closing the page does not stop the server task. Every manual or scheduled run has its own session ID and start time. The screen normally loads the latest ten sessions; use the session filter to avoid confusing an older error with the latest run.
Log types
- INFO: normal steps such as sources, formatter, currency, counts, and batches.
- RULE: loaded inclusion and exclusion filters.
- MANIPULATION: loaded output transformations; it does not necessarily count affected products.
- WARN/WARNING: attention is required, but processing may continue or a specific change may be skipped.
- SUCCESS: Nifelo completed its execution path; this is not proof of external publication.
- ERROR: a step or run failed. Start with the first specific error before a general “Export failed” entry.
- DEBUG: additional technical context for investigation.
Search and investigate
Search by SKU, field, platform, or message and combine it with type and session filters. Clear all filters before concluding that no warning exists. For a failure, select the latest session, inspect ERROR entries, then read the INFO lines immediately before the first concrete cause. Fix the cause, rerun Coverage & quality, and start one new run.
Counts may represent unique selected SKUs, records, mutations, warnings, or skipped products and therefore need not match. Compare them with Selection, Rules, Coverage & quality, and Results.
Download and clear
Download creates a CSV containing all stored sessions with session ID, date, time, type, and message. Save it before clearing or sharing a support case.
Clearing deletes log entries only. It does not undo an export or synchronization, remove external products or files, change configuration, rerun tasks, or repair an error. Important diagnostics are no longer available on this screen afterward.
Files and integrations
For a file export, inspect formatter, currency, processing, excluded prices, filename, and final success entry. File creation does not prove external retrieval. For Shopify and other integrations, inspect connector, batches, skipped changes, and synchronization result. “Skipped” can mean one unsafe mutation was withheld while others succeeded.
Recommended workflow
Filter by session first, read the first concrete cause with its preceding context, treat warnings individually, compare counts, download evidence before clearing, share logs securely, fix the root cause, and verify both Results and the new session after retrying.
What can be recorded?
Depending on the publication method, a session can record the task start, selected data sources, inclusion and exclusion rules, expected product count, formatter or connector, default currency, loaded manipulations, batch progress, skipped mutations, invalid offer prices, excluded zero-price products, generated file, synchronization result, and final status.
Logs contain technical information. Share a download only with authorized people and check it for product or connection details before sending it outside your organization.
Server status and run status
Server online only means that the log interface can reach the Nifelo application. It does not confirm that an external connector or destination platform is available. A run can be queued, processing, completed, or failed. Use the final task status together with the entries from the same session.
Notifications and logs
A success or failure email is a summary. Logs contain the underlying technical detail. If an email differs from what you expected, select the corresponding session and inspect its actual warning, success, and error entries.
Important interpretation
A completed run with warnings may have produced a partial result. A general final error may be caused by an earlier, more specific message. For integrations, an earlier batch may already have been accepted before a later batch fails. Do not retry repeatedly before determining the first root cause: this can create unnecessary work and make the history harder to interpret.
Recommended workflow
- Select the relevant session before searching.
- Read the first concrete error and the INFO entries immediately before it.
- Treat every warning as an item to assess, not automatically as a total failure.
- Compare product counts with Selection and Results.
- Download evidence before clearing logs or making major changes.
- Share log files securely and only with authorized support staff.
- Resolve the root cause before starting another run.
- After recovery, verify both Results and the newly created log session.