To help you understand how the product works and how it’s using your Jira, starting with version 3.2.0 we added the ability for you to see all the incoming and outgoing requests we make. I/O traces are important because it will allow you to understand the I/O we’re doing and to improve the performance of your scripts.
Traces are not enabled by default because the engine is tailored to performance and we’re terrible when it comes for optional features which consume memory. You will find them here:
...
Enabling traces is as simple as pressing on that toggle:
...
| Button handy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
| Info |
|---|
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
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.
To enable the feature, press the Enable traces toggle.
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.silfile in SIL Manager and paste the following script:
| Code Block | ||
|---|---|---|
| ||
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";
} |
Will yield the following information:
...
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 |
...
Because of the update, the issue is then refreshed (there may be other side-effects, from other addons), and after that, the issue is passed into the indexing thread (thread-3) because it seems we have configured some JQL keywords and standard properties, where it is checked for attachments, issue links and comments (with subsequent updates) then we got to a custom property and we execute another SIL file (slen.sil) and store that JQL property as well.
Notice that slen.sil didn’t create any extra call to Jira, otherwise it would be shown as a collapsible section of that table. Indeed, the code in that file reads as:
| Code Block | ||
|---|---|---|
| ||
return length(summary); |
When running a SIL file in a context, we mark the issue the SIL is running, in our case slen.sil run in TEST-10374 context.
All above are product initiated requests, but you would expect to be Jira-initiated requests as well and you wouldn’t be wrong:
The creation and update of the issue has triggered 2 Jira webhooks 1 second apart, and in our particular case we didn’t have any work to do on those Jira webhooks, so we returned immediately. The threads names tells us that there’s a http request involved.
Management of traces
We keep in memory the last 250 traces. A trace is defined as the initiating call, so that trace may contain thousands of actual calls (incoming and outgoing), as we tried to show the call from head to toe. Because of that, it may consume, especially in cases of long operations, an obscene amount of memory.
You can only filter and search the traces that are in memory.
At times, we save the traces as json files in the logs directory. You can download and check them or you can pass them to us for interpreting. Very long traces may be overlapping in multiple such files.
...
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.
|
| The indexing process in Thread 3 is triggered by configured JQL keywords and standard properties.
|
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.