This document explains how to work with the new Request Traces feature introduced in Power Scripts for Jira Cloud version 3.2.0.

Feature Overview

The Request Traces feature provides visibility into Power Scripts' interactions with your Jira instance. When enabled, it logs all incoming and outgoing requests and allows you to monitor how your scripts communicate with Jira and other systems. By analyzing these I/O traces, you can better understand script behavior and optimize script performance.

Request Traces is an optional feature. It is disabled by default to maintain optimal performance. When enabled, Request Traces manages memory resources in the following ways:

Stores the 250 most recent trace operations.
Each trace captures the complete request chain, from the initial call to the final response.
Complex operations may generate extensive trace data, resulting in higher memory usage.

1 Feature Overview
2 How to enable Request Traces
3 How to read traces
4 Working with traces

How to enable Request Traces

In your Jira management console, open the Apps page.
Navigate to the Power Scripts app and click Power Apps Config.
Select Runtime > Traces.

The Request Traces page

To enable the feature, press the Enable traces toggle.

The screenshot shows the Request Traces feature is now enabled.

The Request Traces feature is enabled

How to read traces

When initially enabled, the Request Traces page is empty. It gets populated when you execute scripts. Let’s get started by executing an example script.

Open the test.sil file in SIL Manager and paste the following script:

string newKey = createIssue("TEST", "", "Story", "This issue was created by SIL"); //basic example of creating an issue
if(newKey != null) {
    //some additional changes to the issue after it is created.
    %newKey%.assignee = currentUser();
    %newKey%.labels += "sil_ticket";

}

What this script does is instruct Jira to first, create a new issue, and make two modifications to the issue:

Assign the issue to the current user.
Add the label sil_ticket to the issue.

Run the script.
Go to Power Apps Config > Runtime > Traces.
The Traces page is now populated with a lot of traces. Let’s examine the trace generated by running this script.

	The ID and timestamp of the execution.
	In the expanded primary thread (pool-9-thread-2), you can find the POST request for the initial issue creation.
	The PUT request in the same thread is the issue update. The execution of the script is now complete, but Power Scripts performs some automatic follow-up actions. An issue refresh is triggered by the update, and this includes potential side effects from other add-ons. The issue is passed for an indexing process to Thread 3.
	The indexing process in Thread 3 is triggered by configured JQL keywords and standard properties. The process performs checks for attachments, issue links, and comments with subsequent updates. Next, the script executes a custom property calculation via another SIL file – slen.sil – and stores the JQL property results. Here’s what you need to know about the slen.sil execution to understand the traces in this example: It contains simple code – `return length(summary);` – so it does not generate additional calls to Jira (hence, there is no collapsible section in the trace). It Runs in the context of TEST-10374.

While the trace explained above demonstrates Power-Scripts-initiated operations, you can also find Jira-initiated requests in additional traces logged with separate IDs.

These additional traces capture Jira's webhook activity: two webhooks were triggered in response to the issue creation and update operations, executing approximately one second apart. These webhook requests were completed rapidly since no additional processing was required in this case. You can identify these webhook-related operations in the trace by looking for HTTP-related thread names.

To filter the traces, type a keyword and/or select a specific type of traces you want to view from the drop-down list. The options are Successful, Warnings, and Errors.

Working with traces

Since each trace captures the complete request chain, large operations may span multiple log files and consume a lot of memory. Two automatic safety controls prevent memory-related performance issues:

Only the 250 most recent traces are stored in memory.
The SIL Engine automatically disables trace collection upon restart.

For that reason, the search and filtering capabilities are limited to traces currently held in memory.

Some of the best practices for working with traces include the following:

For complex operations with extensive I/O activity, consider enabling traces only when needed for troubleshooting or optimization.
Trace data is automatically exported as JSON files to the logs directory. These logs can be analyzed locally or shared with support for detailed investigation.