Filter Delta for Jira / Documentation
Set a baseline.
See the difference.
A guide to personal monitors, complete scans and comparisons in Filter Delta for Jira.
Jira Cloud Preparing for public release
Create your first monitor
Filter Delta supports Jira Cloud only. These instructions assume the app is already installed on your site and you have access to it. A public Marketplace installation link is not available yet.
- In Jira, open Apps → Filter Delta.
- Search for a saved filter, enter a numeric filter ID, or enter direct JQL. Use a source you are permitted to access.
- Give the monitor a name. Daily scans are optional; leave them off or enable them.
- Select Create baseline and wait for the queued request to report success.
The first snapshot is the baseline. You need another complete scan later before there is a change to compare. Accepting a queued request does not mean that the scan has finished.
Run a scan
Manual scans
Open a monitor, select Scan now, wait for success, then select Load latest diff or choose a history comparison. Manual scans have a 60-second cooldown and a limit of 5 attempts per monitor per UTC day.
Optional daily scans
When enabled, Filter Delta attempts approximately one automatic scan per monitor per UTC day. It does not guarantee a particular local time. You can pause daily scans.
Background scans use the monitor owner’s Jira access. If that access is lost, or the owner can no longer access a filter or relevant project, a scan may fail. The app does not switch to broader app-level Jira access.
Read a comparison
Added to results means an issue is in the newer snapshot but not the older one. No longer in results means the reverse. Neither label tells you why the result changed.
Compare with the previous snapshot, a selected older snapshot, or one from about 24 hours or 7 days ago. The app shows the actual timestamps used. If no suitable older snapshot exists, that comparison is unavailable.
Issue keys and summaries are current details, fetched when you view the comparison using your current Jira permissions. They are not historical copies. Access changes can affect which details you can see.
When a saved filter changes
If a saved filter’s JQL changes, the monitor pauses and asks for a new baseline. This avoids comparing two different source definitions as though they were the same.
Current limits
- Monitors per user
- 5
- Monitors per installation
- 50
- Issue IDs per snapshot
- 1,000
- Snapshot history
- 14 days; at most 100 snapshots per monitor
- Manual scan cooldown
- 60 seconds
- Manual scan attempts
- 5 per monitor per UTC day
Both snapshot retention limits apply; the stricter limit wins. Expired snapshots are unavailable for display and comparison.
The app does not offer real-time alerts, root-cause analysis, complete audit history, notifications, shared or team monitor administration, CSV export, dashboard gadgets or issue-panel widgets. It may miss an issue that enters and leaves the results between scans.
Licence state and available actions
The current implementation allows baseline creation, scans, baseline resets and daily scans with an active paid or trial licence. When the licence is inactive or unavailable, those operations are blocked. Existing retained history remains readable, and privacy and deletion controls remain available.
This describes app behaviour, not a current offer of a subscription or trial. Public pricing and applicable app terms are not yet published. See terms and availability.
Troubleshooting and support
- No comparison yet? Wait for a second successful scan or choose a retained older snapshot.
- Monitor paused after a source change? Review the saved filter and create a new baseline as requested.
- A scan failed? Check the visible error, your Jira access, licence state and scan limits before trying again.
- Need to remove data? Follow the deletion instructions. These controls remain available without an active licence.
For help with monitors, scans, comparisons, retention, licence states or deletion, use Untiefe support or email info@untiefe.dev. Include the app version if visible, the approximate timestamp and time zone, the visible request or monitor ID, the safe error message, and steps using synthetic or minimal data.
Keep private JQL, account IDs, issue content, passwords and tokens out of the initial message. Support does not include custom JQL development, restoring deleted data, or forensic investigations based on snapshots. Replies are personal and best effort; there is no guaranteed response time or round-the-clock support.