When project management software behaves differently, the fastest useful question is often not "what is broken?" but "what changed, when, and for whom?" A change log gives the investigation a timeline. It should complement vendor audit data, not replace it.
Define the symptom before changing anything
Record the first observed time with time zone, affected workspace or project, affected users, exact action, expected result, actual result, device or browser, and any error text. Save a screenshot when it does not expose restricted data. Determine whether the problem affects one user, one project, or the whole service. Avoid permission, workflow, and integration edits until the symptom is reproducible or bounded.
Build a narrow change timeline
For each recent change, record time, operator, object changed, old value, new value, reason, approval, and rollback method. Include workflow edits, custom fields, permission schemes, group membership, automation rules, app installations, authentication settings, and data imports. Add vendor releases or service incidents as separate entries so internal and external changes are not confused.
Jira Cloud's audit log records many configuration events, including workflow, permission, field, role, and deletion activity. Atlassian says it is intended for configuration changes that affect users and projects, not every activity. The page also notes that the log can be exported to CSV, subject to documented limits, and that a deleted work item cannot be recovered without a prior backup or export. Source: https://support.atlassian.com/jira-cloud-administration/docs/audit-activities-in-jira-applications/
Atlassian also provides an App updates view for changes rolling out to Jira, Confluence, and Rovo, with filters and release information. That is useful when the internal change log shows no corresponding administrative change. Source: https://support.atlassian.com/organization-administration/docs/view-all-changes-to-an-atlassian-app/
Compare, do not speculate
Align the first failure time with the change timeline. Start with changes that affect the same object and users. Compare a working project, role, or workflow with the affected one. Check whether an automation or integration ran at the same time. If the audit log is unavailable under the subscription or does not cover the event, write that limitation into the incident record rather than treating an empty log as proof that nothing changed.
A data export can provide a point-in-time comparison, but its scope must be known. Atlassian says Jira Cloud backups include many core records while excluding categories such as automation rules and third-party app data; it documents separate export steps for automation rules. Source: https://support.atlassian.com/jira-cloud-administration/docs/export-issues/
Test one hypothesis at a time
State the hypothesis in the log: for example, "the new permission scheme removed access for this group." Record the expected observation, run the least disruptive read-only check, and write down the result. If a change must be reversed, use a supported rollback and record the exact before-and-after state. Do not change several permissions, workflows, and apps at once; that destroys the evidence needed to know which action worked.
Test the affected action with a designated test item or isolated project when possible. Confirm that normal users, administrators, automations, notifications, attachments, and integrations still behave as intended. If restoring from a backup is being considered, follow the recovery plan and test the restore separately from the live workspace.
Close the investigation clearly
The final entry should name the confirmed cause, evidence, correction, verification steps, affected period, and any work that must be reconstructed. Mark unconfirmed theories as unconfirmed. Export or retain relevant audit evidence according to the organization's security and retention rules.
A change log is valuable because it prevents troubleshooting from becoming a sequence of undocumented guesses. It turns each test into evidence and leaves a repeatable path for the next incident.
Sources
- Audit activities in Jira — Atlassian Support
- View all changes to an Atlassian app — Atlassian
- Export data from Jira Cloud — Atlassian Support