Data Logging

Effective October 28, 2026

App	TreeCraft: Issue Hierarchies, a Jira Cloud app built on Atlassian Forge
Marketplace listing	Coming. TreeCraft is not on the Atlassian Marketplace yet, and its app key will be added here when it is.
Forge app ID	ari:cloud:ecosystem::app/2f99b935-aba0-4b23-8784-05691aaac4b9
Vendor	Plugincraft Software inc., Québec, Canada

The short version

App logs hold ids, counts, statuses and error codes.
They never hold work item summaries, query text, field values, names or email addresses.
An automated test fails the build if code logs anything else.
Atlassian keeps the logs, and does not keep them in your site's data residency location.

What the logs are

When a Forge function of the app runs, it can write log lines. Atlassian keeps them and makes them available to Plugincraft as the developer. The app uses no outside logging service. Because logs are not kept in your site's data residency location and the developer can read them, the app never puts customer content in them.

What a log line may hold

Kind	Examples
Ids	A hierarchy id, an item id, rule row ids, a queue name with the ids of its work, a version number.
Counts and attempts	How many work items a job checked, changed, dropped or could not read; how many attempts a retry made.
Statuses and reasons	The HTTP status of a call to Jira; the reason and wait of a "too many requests" answer; of an error, only its kind, code, status and where it was thrown (the first stack frames).
The app's own names	A resolver name, a job kind, a queue name, a REST route id, and the module type and key the platform names for a refused call. These are names from the app's manifest.
Jira points	Once a minute per instance, what Jira says is left of the app's per-second burst limit, as numbers and a UTC time. A call or job that spends 100 points or more logs its points and requests by route, with ids left out, for example /rest/api/:x/issue/:x/changelog.
REST API timing	One line per call: the route id, the status, the app's error code, milliseconds by phase, and the counts of database statements and Jira requests.

What the logs never hold

Work item summaries, descriptions, comments or field values.
Query text (JQL or tree queries), formulas or notes.
Names of hierarchies, folders, people or fields.
Email addresses.
The words of an error message. Jira's answers, a query's text and a value's own words end up in error messages, so the app logs only the error's kind, code, status and where it was thrown. Jira's answer to a failed call is kept in memory for the code and never logged.
The path, query or body of a REST API request.
Credentials or tokens. The app keeps none.

How this is enforced

Every log line goes through one function in the app. It writes what failed with ids, counts and statuses, and of an error only its kind, code, status and frames.
An automated test fails the build if code logs any other way, or if a log line shows anything other than the ids, counts and names it allows. The test covers all of the app's server code, including the REST API.
A name is added to the allowed list only once it is known never to hold customer content.

Retention

Atlassian sets how long Forge keeps app logs. Retention period: 30 days. Atlassian's documentation for app developers says: "Logs are only available for the past 30 days." Plugincraft does not copy logs to any other system, and reads them only to find and fix problems. A site admin can turn off the developer's access to their site's logs at any time.

The support bundle

The support bundle is not a log. An admin builds it in the app to send to support. It holds versions, settings, counts and ids, and no work item text, field values or email addresses. The admin can show the whole file before sending it, and decides whether to send it. Support emails are kept as described in the privacy policy.

Data Handling: Retention and Deletion
Architecture Diagram and Data Flow (password protected: request access at info@plugincraft.ca)
Security overview
Privacy policy