Why Use Log Monitoring    

Use Log Monitoring to:

• Investigate failed executions

• Monitor workflow and automation activity

• Debug custom scripts and functions

• Track API activity

• Analyze execution performance

• Trace relationships between components

• Identify abnormal activity patterns

• Create alerts for critical events and threshold breaches

Pre-requisite 

To access Logs and Monitoring, users must have the View System Logs permission enabled in their organization profile.

To grant this permission:

1. Navigate to Settings >> User Management >> Organization Profiles.

2. Select the required organization profile from the left pane.

3. Under User Log Permissions, enable View System Logs.

4.  Save the profile.

Only users assigned to profiles with the View System Logs permission can access and search logs in the Logs and Monitoring module.

Understanding Log Types      

Logs are categorized based on the type of activity being recorded. Each log type captures information from specific Qntrl modules.

Supported Modules by Log Type   

Module	Access	Application	Execute	Schedule
Cards	✓	✗	✗	✗
Circuits	✓	✗	✓	✗
Circuit States	✗	✗	✓	✗
Functions	✓	✓	✓	✗
CodeX	✗	✓	✓	✗
CodeX SDK	✗	✗	✓	✗
Scripts	✗	✓	✗	✗
Bridge Messages	✗	✓	✗	✗
Messages	✓ (Execution)	✗	✓	✗
Business Rules	✗	✗	✓	✗
Webhooks	✗	✗	✓	✗
Transitions	✗	✗	✓	✗
Scheduler	✗	✗	✗	✓
Other Modules	✓ (API only)	✗	✗	✗

 

Access  

Use Access Logs to monitor incoming API requests and supported web-triggered activities in Qntrl.  

Access Logs capture:

• All API requests made to Qntrl, including requests from external clients, such as Postman, applications, and AI agents.

• Supported user actions performed through the Qntrl web application.

Not all web-triggered activities are captured in Access Logs. Only the following user actions are supported.

 

Module	Web	API
Card	Create, Update, Delete	Yes
Circuit	Create, Update, Delete, Circuit Executions	Yes
Functions	Create, Update, Delete, Function Executions	Yes
Messages	Execution only	Yes
Other Modules	No	Yes

  

What Data Is Available?    

Access Logs provide the following information for each request.

• Log Details  : Log Type, Module, Timestamp, Remote IP Address

• Request Details  : HTTP Method, Request URL, Response Status Code, ZUID

• Parameter Details  : Parameter names and values, Sensitive parameter values are masked

  

Use Cases    

• Audit API activity

• Troubleshoot failed requests

• Analyze request and response behavior

• Investigate card, circuit, function, and message execution activity

• Track supported user actions performed through the Qntrl web application

 

Application  

Use Application Logs to view messages generated by Functions, CodeX scripts, Scripts, and Bridge Messages during execution.

What Data Is Available?   

• Log Details  : Log Type, Module, Timestamp, Log Level (INFO, ERROR, WARNING)

• Message Details  : Message content generated during execution

 

Use Cases   

• Search for specific messages generated during execution

• Identify errors and exceptions quickly

• Debug Functions, CodeX scripts, and Bridge Messages

• Track execution flow and runtime behavior

• Investigate execution failures

 

Example:

Consider a Circuit that executes a Function.

If the Function contains the following statements:

console.log("File download started");
console.error("Unable to download file");
console.warn("File size exceeds recommended limit");

The generated messages are captured in Application Logs.

To search for a specific message:

logtype="application" and message contains "Unable to download file"

To search for all error messages:

logtype="application" and level contains "error"

 

Execute 

Use Execute Logs to monitor the execution status of backend automation components in Qntrl. Execute Logs record executions performed by Qntrl services without direct user interaction.

Execute Logs do not contain user-specific information such as ZUID or Remote IP Address.

 

What Data Is Available?   

• Execution Details  : Log Type, Module, Status (Success or Failure), Timestamp

  

Use Cases   

Execute Logs help you:

• Verify whether an automation executed successfully

• Investigate Business Rule, Circuit, Function, and Webhook failures

• Analyze automation execution behavior

• Track backend workflow activity

• Monitor execution history

 

Example  

Consider a card update that triggers the following automation flow:

Card Update
└─ Business Rule
      └─ Circuit
           └─ Function
                └─ Webhook

Each automation execution is recorded as an Execute Log.

You can use Execute Logs to identify:

• Which component executed

• Whether the execution succeeded or failed

• When the execution occurred

 

Schedule  

Use Schedule Logs to monitor executions triggered by Qntrl Schedulers.  

What Data Is Available?   

• Execution Details  : Log Type, Module, Status (Success or Failure), Timestamp

 

Use Cases   

Schedule Logs help you:

• Verify whether scheduled tasks executed successfully

• Investigate scheduler failures

• Monitor recurring task executions

• Track schedule execution history

 

Example  

Consider a Scheduler configured to execute a Circuit every day at 9:00 AM.

Each scheduled run generates a Schedule Log indicating:

• When the scheduler was triggered

• Whether the execution succeeded or failed

• The execution timestamp

You can use Schedule Logs to verify that scheduled automations are running as expected.

Search Logs 

Use the Query Builder in the logs page to search logs based on log type, module, status, and time range.

Build a Query 

1. Log in to Qntrl.
2. Navigate to Settings >> Log Monitoring >> System Logs.
3. You can build a query using one of the following methods (Filters / Query Editor)
1. Filters – Use the available filters to build queries for common log searches. As filters are selected, the corresponding query is generated automatically.
1. Log Type – Select the type of logs to search. Refer to Understanding Log Types for more information.
2. Module – Select the modules for which logs should be retrieved.
3. Status – Select one of the following:
1. Success
2. Failed
4. Time Window – Select a predefined time range or specify a custom time range.
5. Use Clear All to reset the selected filters and create a new query.
2. Query Editor – You can manually enter a query in the Query Editor to perform advanced searches and define custom search conditions. For more information, refer to Query Auto-Suggestions and Advanced Search.
1. Search using multiple conditions.
2. Use supported operators and functions.
3. Query fields not available through filters.
4. Create complex log searches.
4. Click the Enter icon to execute the query.
   

The time window is applied using the time window filter and is not included in the query.

Example 1: Search successful CodeX executions

To view successful CodeX executions from today, use the following filters:

• Log Type: Execute

• Module: CodeX

• Status: Success

• Time Window: Today  

Respective query:

 logtype = "execute" and module contains "codex" and status contains "success"

Example 2: Search Failed Executions Across Multiple Modules  

To view failed executions from the past week for CodeX and Functions:

• Log Type: Execute

• Module: CodeX, Functions

• Status: Failed

• Time Window: Custom Range (Last 7 Days)

logtype = "execute" and module in ("codex" , "function") and status contains "failed"

 

Auto-Suggestions   

The query editor provides intelligent suggestions for supported log types, fields, operators, and values while building queries.

To view available suggestions, place the cursor in the query editor and press the Spacebar key.

Use auto-suggestions to:

• Discover available fields

• Identify supported values

• Build queries faster

• Avoid syntax errors

For detailed information, refer to Auto-Suggestions and Query Language.

View Query Results   

After a query is executed, matching logs are displayed in a table.

You can:

1. Sort results by:
1. Newest First
2. Oldest First
2. Navigate through results using pagination controls
1. Default: 10 logs per page
2. Maximum: 60 logs per page

Save Queries   

Use saved queries to quickly access frequently used searches.

To save a query:

1. Build and execute a query.

2. Click Save Query.

3. Review the generated query.

4. Enter a name for the query.

5. Click Save.

Saved queries can be accessed from the Saved Queries dropdown.

• Only the query definition is saved. Time-based filters are not saved and must be selected each time the query is executed.

• Modified saved queries can only be saved as a new query.

• Only the query name can be edited using the edit icon available next to the query name in the Saved Queries dropdown.

• Saved queries are shared across the organization.

• Users with access to Logs can view saved queries created within the organization.

  

Additional Actions    

Create Alerts   

Use alerts to monitor specific log conditions and receive notifications when matching events occur.

To create an alert:

1. Build a query.

2. Click Create Alert.

3. Configure the alert on the Alerts page.

For detailed instructions, refer to Alerts.

Refresh Results   

Click Refresh to re-execute the current query and retrieve the latest matching logs.

View Portal Time   

The time displayed at the top of the page reflects the portal's configured time zone.

View Log s and Debugging

Each log entry includes actions that help you investigate executions, trace component relationships, and debug issues.

The following actions are available next to each log entry:

• Log Details – View detailed information about the selected log entry. For more information, see View Log Details.

• Trace Tree – Trace execution flow and understand relationships between components. For more information, see View Trace Tree.

• Related Logs – Navigate between Application Logs, Access Logs, and Execute Logs. This action is available only for script-based modules such as Functions and CodeX. For more information, see View Related Logs.

View Log Details  

Use the Log Details icon to examine a log entry and understand why a request or execution succeeded, failed, or behaved unexpectedly.

Available Information  

The Log Details window provides comprehensive information about the selected log entry, including:

• Log Type

• Module

• Timestamp

• Message

• Parameters

• Correlation IDs

• Request Parameters

• Remote IP

• Additional execution details

This information helps identify the cause of issues and analyze execution behavior.  

View Tree

You can directly open the Trace Tree from the Log Details window by clicking View Tree. This helps you visualize the execution flow and relationships between components.  

Create an Alert   

• Click Create Alert at the bottom of the Log Details window to create an alert for the selected log activity.

• The alert configuration page opens with the relevant query details pre-populated, allowing you to quickly configure notifications and monitoring. 

• Refer to Alert for detailed configuration instructions.

View Trace Tree  

Use the Trace Tree icon to understand how components interact during an execution and identify what triggered a process.

Complex business processes often involve multiple components triggering one another.

Example:

Card

└── Business Rule

└── Webhook

└── Circuit

└── Circuit

└── Function

The Trace Tree provides a hierarchical view of these relationships and helps you understand the complete execution path.

The Trace Tree provides the following actions to help you analyze execution flow:

Open Parent / Open Child     

• Open Parent: Displays the component that initiated the current execution.  

• Open Child: Displays components executed by the selected component.

View Log Details 

Click any component in the trace tree to open its log details and inspect execution information for troubleshooting.

Create Alert   

You can create an alert for the selected log directly from the Log Details window.

Click Create Alert to open the Alert Configuration page, where the relevant query details are pre-populated. Configure the alert to receive notifications for successful or failed executions.

For more information about configuring alerts, refer to Alerts.

Trace Logs using QThread ID     

Use the QThread ID (qthread_id) to identify and trace all logs that belong to the same execution flow.

A business process may involve multiple components such as Business Rules, Circuits, Webhooks, and Functions. All related activities share the same QThread ID, making it easier to trace the complete execution path across modules.

Trace Parent Executions using Parent Access ID     

Use the Parent Access ID (parent_access_id) to determine which component directly triggered the current execution.

Example:

Card

└── Business Rule

└── Webhook

└── Circuit

└── Circuit

└── Function

Parent Access IDs help reconstruct execution hierarchies and understand how components are connected.

View Application Logs  

Use the Application Logs icon  to identify the execution that generated a application log or to view all script logs generated during an execution.

This feature is available for script-based modules such as Functions and CodeX.

It helps correlate:

• Application Logs

• Access Logs

• Execute Logs

It also helps you understand the relationship between a script execution and its associated logs.

From Application Logs to Execute Logs   

When searching using a logger message:

1. Locate the matching Log.

2. Click Application Logs icon  .

3. Open the Access Log or Execute Log that generated the message.

This helps identify:

• Execution details

• Request information

• Execution status

• Execution duration

• Related metadata

From Execute Logs to Application Logs   

When viewing an Access Log or Execute Log:

1. Click the Related Logs icon  .

2. View all Application Logs generated during that execution.

This helps identify the sequence of events and quickly locate the step where an issue occurred.    

Limitations   

Log Indexing Delay   

Log data is indexed before it becomes searchable. As a result, newly generated logs may take a few seconds to appear in search results.

If a query does not return the expected logs:

• Verify that the query criteria are correct.

• Wait a few seconds and execute the query again.