-
Notifications
You must be signed in to change notification settings - Fork 15
Watchtower Settings
Watchtower β Settings decides which cards appear on the dashboard and what each figure is counting.
Everything here trims a dashboard that is already correct. Leave the whole screen alone and Watchtower behaves exactly as it does out of the box: every card drawn, every status counted. Nothing needs configuring for the numbers to be right.
The statuses these settings refer to are created and renamed in their own modules β ticket statuses under Tickets, task statuses under Tasks, impact levels under Service Status.
But "show this one on my dashboard" is not a fact about a status. Your statuses carry their own facts β whether they count as closed, which one is the default, whether they pause the SLA clock β and the SLA engine and much else depend on those. One dashboard's preferences have no business mixed in with them.
Practically, it also means you tune Watchtower in one place instead of touring three other modules' settings screens looking for it.
Each row on this screen is tagged with the module it affects, in that module's own colour, so it stays obvious which part of FreeITSM you are changing.
Ten cards, each on or off. Turn off the ones your team does not watch.
| Card | What it shows |
|---|---|
| Morning Checks | Whether today's round has been done, and how it went |
| Tickets | Open tickets by status, high priority, unassigned, paused too long |
| Changes | Open changes by status, awaiting approval, in progress, scheduled |
| Calendar | Today's events and the week ahead |
| Service Status | Degraded services and open incidents |
| Contracts | Contracts expiring and notice periods running out |
| Knowledge | Recent articles and reviews now overdue |
| Assets | Warranties expiring and assets not seen recently |
| Tasks | Open tasks by status, overdue and due today |
| Workflows | Failed or aborted runs, and webhooks that have stopped delivering |
Hiding a card changes nothing but your dashboard β each module still shows everything in its own screens.
Each of these counts every status you have, which is why a status you rename or add keeps working without being mentioned anywhere in here. Narrow one only if a card is showing more than you want to read at a glance.
Every entry has the same shape: leave "choose specific ones" off to include everything β now and anything added later β or turn it on and tick the ones you want.
| Setting | Module | What it decides |
|---|---|---|
| Ticket statuses shown | Tickets | One figure per open status, plus a total. The total always matches what is listed beside it |
| Priorities counted as high priority | Tickets | The red "high priority tickets" line. Left alone it means any priority ranked above your default one, so a new priority added above it is included automatically |
| Change statuses shown | Changes | One figure per open change status, plus a total |
| Impact levels shown on the card | Service Status | Which levels put a service on Watchtower. Left alone, anything other than your healthy level does |
| Impact levels that turn the light red | Service Status | Everything else shows amber |
| Task statuses shown | Tasks | One figure per open task status, plus a total |
| Morning check statuses that need attention | Morning Checks | Which results count as a problem |
| Paused too long | Tickets | How many hours a ticket may sit with its SLA clock stopped before Watchtower mentions it |
Morning check statuses that need attention. Nothing in FreeITSM records which of your morning-check statuses is a pass and which is a problem β they are just labels with colours, and you can rename them. Until you say, the card assumes only the first status in your own order is good, and it never claims your checks have passed, only that they are done. Tell it which statuses mean trouble and it will use that instead.
Impact levels that turn the light red. This is kept separate from the counts as downtime setting on each impact level, on purpose. That one decides your uptime percentages β a reporting fact. If the two were the same setting, wanting a degraded service drawn amber would mean falsifying your uptime figures to get it. Left alone, this follows counts as downtime, so nothing changes until you say otherwise.
This threshold has been read on every dashboard load since it was added and, until now, could only be changed by editing the database directly. It has a box on this screen.
It governs the "N tickets paused over Nh (SLA clock stopped)" line, which is there to surface tickets being parked in a paused status to escape the SLA clock. The default is 24 hours.
Two separate permissions, because they carry different risk:
| Permission | Covers |
|---|---|
| Choose which cards appear on Watchtower | The Cards tab. Hiding a card tidies a screen |
| Choose which statuses and priorities each Watchtower count includes | The Counts tab. Narrowing a count changes what a number means β the figure everyone reads each morning quietly changes definition |
Neither grants any access to the modules being counted. Each card already shows only what you are allowed to see.
A tab you do not hold is never drawn, and the Settings link only appears for analysts who hold at least one of them. See Roles and permissions.
- Watchtower β the dashboard itself
- Watchtower settings β Developer Guide β the storage model and how to add a new setting
- Browser extension β the same figures in your toolbar
- Never identify a lookup row by its name β why the counts read flags rather than words
- Roles and permissions β granting the two capabilities
FreeITSM β an open-source IT Service Management platform Β· github.com/edmozley/freeitsm Β· MIT licence
- Installation
- β° Scheduled tasks (cron jobs)
- Architecture
- AI Providers
- Internationalisation (i18n)
- Timezones & Time Handling
- Theming & Dark Mode
- β¨οΈ Command palette (βK)
- π Searching inside tickets
- π Attached documents
- MobileβFriendly
-
Security
- Layer 1 β which modules you can enter
- β³ π§© Module Access Control
- β³ π οΈ Module Access β Developer Guide
- Layer 2 β what you can administer
- β³ π Roles & Permissions
- β³ π οΈ Roles β Developer Guide
- β³ π€ Why capabilities are constants
- Layer 3 β the System module
- β³ π Admin Access Control
- Hardening
- β³ π Security review response 2026-08
- β³ π‘οΈ Security hardening 2026-08
- β³ π οΈ Security hardening 2026-08 β Developer Guide
- β³ π‘οΈ Round three β plain English
- β³ π οΈ Round three β Developer Guide
- Single Sign-On (SSO)
- ποΈ LDAP & Active Directory
- Browser Extension
- API Reference
-
π REST API β how it works
- β³ π« REST API: Tickets
- β³ π» REST API: Assets
- β³ π΄ REST API: Problems
- β³ π REST API: Changes
- β³ π REST API: Knowledge
- β³ β REST API: Tasks
- β³ ποΈ REST API: CMDB
- β³ π REST API: Contracts
- β³ ποΈ REST API: Calendar
- β³ πΏ REST API: Software
- β³ π¦ REST API: Service Status
- β³ βοΈ REST API: Morning Checks
- β³ π REST API: Forms
- β³ βοΈ REST API: Workflow
- β³ πΊοΈ REST API: Network Mapper
- β³ π§ Using the API docs page
- β³ π OpenAPI specification
- β³ β OpenAPI: kept correct
- β³ π οΈ Maintaining the catalogue
- Watchtower
-
Tickets
- β³ Mailbox Authentication
- β³ π€ Email send log
- β³ Basic IMAP mailboxes
- β³ Email rendering & images
- β³ SLA Management
- β³ WhatsApp channel
- β³ π¬ Web chat channel
- β³ π£ Slack channel
- β³ π Linking tickets
- β³ ποΈ Canned responses
- β³ βοΈ Limiting replies to particular senders
- β³ βοΈ Email signatures
- β³ π The public web address
- β³ π’ Ticket numbering
- β³ π Raising a ticket for someone else
- β³ π Merging tickets
- β³ β Splitting tickets
- β³ β Selecting several tickets
- β³ π οΈ Snoozing tickets β Developer Guide
- β³ π₯ Collision detection
- β³ β±οΈ Time tracking
- Problem Management
- Tasks
- Assets
- Knowledge
- Change Management
- Calendar
- Morning Checks
- Reporting
- Software
- Forms
- Contracts
- Service Status
- π Notifications
- π¨ War Room
- Self-Service Portal
- LMS
- Process Mapper
- CMDB
- Network Mapper
- Workflows
- Issue trackers (Jira, Azure DevOps)
- System
-
Overview
- β³ π Progress tracker
- β³ Concepts & vocabulary
- β³ Email routing & mailboxes
- β³ Settings: global vs per-company
- β³ Users & self-service
- β³ Staff cross-company access
- β³ Worked examples
- β³ Pitfalls & gotchas
- β³ Scope: what it's for
- β³ π οΈ Developer Guide (make a module multi-company)
- β³ ποΈ Case study: CMDB (a linked graph)
- β³ π§ͺ Test harness (prove it's isolated)