Expired, expiring within the warning window, in warranty, and no data. Press a tile to filter the table to it, or search by device name or serial number.
| Status | When |
|---|---|
| Expired | The warranty end date is before today. |
| Expiring | Between today and the end of your warning window — 60 days by default. |
| In warranty | Further away than the warning window. |
| No data | There is no end date, and the device carries one of five reasons why. |
The status you see is worked out from the warranty end date at the moment you look at it, by the one function allowed to decide a status. A status string is stored as well, but only so the estate can be indexed on it — nothing displays it. So nothing has to run for a device to cross from in-warranty to expiring on the right day: not a sync, not a manufacturer, not a scheduled job that might have failed overnight.
It is never a shrug. A device with no data carries one of five reasons, in the app’s own words: not checked yet, no serial number, a manufacturer the app does not cover, the manufacturer returned no warranty for that serial, or the manufacturer could not be reached and the next sync will retry.
The pre-scan needs no credentials. It reads your estate, classifies each device by manufacturer, and reports the counts — including the ones it cannot help with, and why.
An expiry issue is raised while there is still time to do something: renew, replace, or decide deliberately not to. It carries the facts the decision needs, in the project you chose, on your issue type.
The device, its manufacturer, serial number, warranty end date and service level, with a link back to the device record. It sets no assignee or priority, so the expiry project’s defaults apply.
Each issue carries a machine key in its summary, [WS:deviceId:warrantyEnd], and the labels warranty-sync and ws-deviceId. Because those live in Jira rather than in app storage, de-duplication survives the app being uninstalled and reinstalled.
Those labels join your site’s shared label namespace and will appear in label pickers for everyone. That is worth knowing before you switch ongoing issues on.
![Illustration of a per-device expiry issue, with sample data, titled Warranty expiring: Latitude 5540 · LT-0214 [WS:10734:2026-09-19]. Its description, written by WarrantySync, lists the device, the manufacturer Dell, the serial number 7KX2P9Q, the warranty end 2026-09-19, 6 days away, and the service level ProSupport Plus, then links to the device and says the issue will not be raised again for the same expiry date. It carries the labels warranty-sync and ws-10734; the reporter is WarrantySync and nobody is assigned.](/screenshots/expiry-issue.webp)
The repair-or-replace decision happens on a ticket, not on a dashboard. The warranty card puts the answer there: status, end date, days remaining and service level, with the date it was last checked so nobody has to trust it blindly.
Settings are split so that a change to one thing cannot quietly resave another. A tab with unsaved changes says so.
Assets or Jira work items, then the schema and object type, or the project and issue type. Press Discover fields and the app proposes a mapping for serial number, manufacturer, model and warranty end.
One card per manufacturer, each with a connection-state lozenge and a Test connection button that makes one real call. Credentials go into Forge’s encrypted secret storage. The app reads them to authenticate and returns them to nobody: no screen, log line, export or API response gives one back.
The warning window, how stale a record may get before it is looked up again, the hour of the day the real run happens, the request budget per minute, and whether dates are written back to your devices. Every one is bounded and validated, and the message names the field.
Whether the app may create issues at all, the project and issue type they are raised in, the style — one per device, or one digest an issue at a time — and the per-run cap.
Which field on a work item names the device the panel should show. Set it and the warranty card appears on your hardware work items.
Press Discover fields and the app reads the fields or attributes that already exist and proposes a mapping for serial number, manufacturer, model and warranty end. Use suggestions puts the proposal in the dropdowns. You confirm or override every one, and nothing is saved until you do.
If there is no warranty end date field, it says so and tells you what to create — a Date field called Warranty end on your devices — then offers to look again. It will not create one for you. A field the app invents is a field your site is left with after the app is gone.
These settings say where an expiry issue would be raised and what it would look like. Ongoing issue creation is a separate switch, on the dashboard, and it starts off.
The one thing that is not behind that switch is the summary issue the first completed sync raises. That is deliberate: it is how an administrator finds out the app is working. If you want nothing raised at all, turn off Allow WarrantySync to create issues. Leaving the project unset instead keeps a warning on the dashboard until you choose one.
The export is the whole estate in warranty-end order, earliest first — not the tile filter or the search you currently have applied, and capped at 2,000 rows. On a larger estate you get the 2,000 earliest end dates, which on an estate with a long expired backlog means the backlog rather than what is coming, and the modal states the cap rather than trailing off.
Values are escaped against CSV formula injection, so a device name beginning with an equals sign stays a device name when the file is opened in a spreadsheet. The export is open to any licensed Jira user, as the dashboard is, and it is unavailable while a run is in progress.
Every warranty date in this app comes from the manufacturer that sold the machine. We do not generate it, correct it, or independently confirm it. If a manufacturer’s record is wrong — a transferred machine, a warranty extension it never registered, a serial that is an asset label rather than a service tag — then the status shown here is wrong in exactly the same way, and the issue raised is wrong with it.
That makes it a monitoring aid, not a system of record. It is built to tell you where to look and when, which is the part that usually goes undone. Before you act on one machine — a renewal, a disposal, a claim, a purchase order — confirm it with the manufacturer or with your own purchase record. The End User Terms say the same thing in clause 9.5, and we would rather it were on this page than only in that one.
Any edition, Free included. Jira Service Management Assets is optional — if you have Premium or Enterprise the app can use it, and if you do not it works against hardware tracked as Jira work items.
Dell, Lenovo or HP, or any combination. The app ships with none and works in pre-scan mode while you wait for them.
A warranty lookup is a serial number lookup. A device with no serial cannot be looked up by anything, and the pre-scan counts them for you before you find out the hard way.
Beyond that the app is unsupported rather than blocked: there is no device counter, and what you would see is a banner the first time the entity store refuses a write.
Published rather than discovered. Each is a real constant in the code, and each is here because it is the kind of thing you would otherwise find out on the day it mattered. The settings ranges are on the How it works page; these are the limits you cannot change.
| Limit | Value | Detail |
|---|---|---|
| Estate size | 10,000 devices | The supported limit. There is no device counter: the dashboard shows a banner when the entity store refuses a write because it is full, whenever that happens to be. |
| CSV export | 2,000 rows | The whole estate in warranty-end order, earliest first — never the tile filter or the search. The modal states the cap rather than trailing off. |
| Devices in a digest issue | 200 | The rest are held over and the issue says how many. |
| Device search | 1,000 records a request | Searched in warranty-end order, earliest first. If the estate is larger, the search offers Keep looking and says it has not reached the end yet, so a match further in is still reachable. |
| Expiry issues per run | 25 by default, 1 to 100 | Anything over the cap is raised on the next run, counted and stated on the dashboard, never silently dropped. |
| Sync now cooldown | 10 minutes | A refused run always names its reason. |
| Check now cooldown | 15 minutes per device | Separate from the above, because Check now spends a real manufacturer lookup on one device. |
| Run log | the last 100 batches | Older entries are dropped. The entity store has no count query, so one page is the only retention target that can be relied on. |
| Removing a departed device | after 60 days | Twice the re-check age, and only once your site has confirmed the device is gone. At most ten of those confirmations per page, so a large clear-out takes several runs. |
Each of these is a decision rather than a gap, and each has a reason worth stating.
Rows arrive one page at a time, so a sortable column would sort the fraction already fetched and present it as the whole estate. Export and sort there, until sorting can be done server-side.
The warranty card appears on Jira work items. Assets object views are not a surface this version renders into.
Dell, Lenovo and HP. Adding a fourth is one adapter file, one registry line and one manifest host — but it is not there until it is there.
You choose a schema and object type, or a project and issue type. You cannot yet say “only the devices matching this JQL”.
It tracks manufacturer warranty end dates. It is not an asset lifecycle suite, a purchasing system or a contracts database.
It will not create a custom field, an Assets attribute or an object type in your site. This one is not a roadmap item; it is a rule.
If one of them rules the app out for your estate, we would rather you knew now. Tell us which, and it goes on the list.
