Troubleshooting

Every message quoted below comes from the app itself. The panel sits on the work item under Statuswatch; the settings page is under Apps → Statuswatch in the project's settings.

The panel shows calendar time although working hours were configured#

When a calendar applies, the panel shows a Counted in line naming it. If that line is missing, no calendar applied: either Count business hours only is off, or this project was never configured — which shows calendar time with no warning. The setting is per project, so another project's calendar has no effect here.

A warning about working hours appears#

This project’s working hours could not be read just now, so the times below are calendar time — nights and weekends included.

App storage could not be read while the panel loaded. Nothing was written and no settings were lost. Anything that spanned a night, a weekend or a holiday now reads larger than the configured hours would give. Reload the work item.

A warning about status names appears#

Status names and categories could not be read just now, so a renamed status may show its old name.

Rows fall back to the names the change history recorded at each transition, so a renamed status can appear as two rows. Every bar except the current status's turns the same grey as a To do status, and the category rollup line is dropped. Reload the work item.

The panel says the history is truncated#

This issue has more status changes than the panel can read, so the earliest part of its history is missing.

The panel reads at most twenty pages of a thousand status changes, newest first, so what is missing is the oldest part — including the status the item was created in. The time before the cut lands on the earliest status that survived, making that row too large, and the footer's status-change count is a lower bound. The total still covers creation to now, or to done.

A duration is not moving#

Check the panel for a blue note such as Outside working hours just now. The clock is paused, counting again tomorrow at 06:30. Under business hours nothing accrues outside the calendar, so a stay that began after the working day ended reads 0m until the next working morning. The note names the reason — holiday, non-working day, outside the hours, or the break — and the time counting resumes. Each calendar reads in its own time zone, which need not be yours.

On a finished item there is no note, because the clock has stopped for good: the status the item sits in carries a green done marker instead of current.

A status shows 0m although the item was in it#

Rows at 0m with an empty bar are the statuses the item has never entered — listed so that what it skipped is visible. If a status the item really did pass through shows 0m, its whole stay fell outside working hours; <1m, by contrast, means measured time under a minute.

The list comes from the item's own work type, so a bug and a story in one project show different statuses. A status missing from it is not in that work type's workflow.

The panel shows nothing#

• A spinner and nothing else: still loading.
• No status history for this issue yet. — no usable creation date came back for the work item.
• Could not read this issue history. — the read failed. Every call runs as the signed-in user, so someone who cannot browse the project is denied.
• Could not load the status history. — the panel's call to the app did not come back.

The clock has not stopped on a finished item#

The clock stops on the statuses at the end of the history whose category is Done — not on the status name, and not on the resolution. A status called Closed that its workflow maps to In progress goes on accruing time, and the footer keeps reading Total time since creation:. The fix is a workflow change in Jira, not a setting here. A reopened item keeps its earlier done time: only that trailing run is dropped.

The settings page will not load, or will not save#

If the page shows only a spinner, with no message, its call to the app did not come back. Reload the page.

If app storage cannot be read, the page opens on the defaults instead, as though the project had never been configured: business hours off, one calendar named Default, this browser's time zone. A save from that state is refused with the Someone else saved these settings message below. Reload before changing anything.

A refusal appears in an error message under Save. If the save call never returns, Save stays loading and nothing appears — reload the page to see whether the change was stored before retrying.

A holiday is not skipped#

A holiday line starting with # is kept as a comment and never applied — it saves without an error and is not listed in the working-hours dialog. Remove the # for the date to count.

Two calendars seem to fight over one issue#

Click the calendar name after Counted in: the dialog says which calendar applied and on which value, or that it is the project's fallback.

• One rule per project, set by For this project, apply calendars by. While that is Nothing — one calendar for everything, only the first calendar is used.
• The first calendar is the fallback and claims no values. The rest are tried in order and the first match wins, ignoring case and surrounding spaces.
• Calendars cannot be reordered. Remove the shared value from whichever calendar should not claim the item.

Durations look wrong#

• Each calendar has its own time zone, which need not be yours: its working days, window and holidays are read in that zone, so a duration that looks shifted by a few hours is often the zone.
• Time outside working hours counts as nothing: an item created at 18:00 under a 09:00–17:00 calendar has no working time until the next working morning, and reads 0m until then. Measured time under a minute reads <1m instead.
• 1d is one working day, not 24 hours. The dialog's A working day line gives its length in real hours.
• Every duration keeps its two largest units and drops the rest, so a row reading 2d 3h has lost up to 59 minutes. Totals add the exact values first, so long rows can sit under a total an hour or more larger.
• Bars have a small minimum width, so a brief status stays visible. Read the duration beside the status name, not the width of the bar.
• A due date has no time in Jira, so the app takes the end of that day, in the calendar's own zone: the end of the working window, or midnight. Overdue is decided by the wall clock, not by working time.