Skip to content

Organisation settings

Organisation → Settings is where your organisation configures itself. Everything on it applies to this organisation only, and is changed by its own members: limits that WatchTower15 sets are shown here, read-only.

The page has three tabs, each with its own address, so you can bookmark a tab or send someone a link to it:

Tab Address Cards
Info /organisation/settings/info Organisation, Account Limits, Recent settings changes
Authentication /organisation/settings/authentication Sign out every member, Single Sign-On (SSO), Two-factor authentication, Password Management, API Keys
Monitoring /organisation/settings/monitoring Server Monitoring

/organisation/settings opens Info.

Every card shows its settings read-only. A card you can change has an Edit button that opens the card’s own page: change what you need, then Save, which confirms with Saved and takes you back to the tab, or Cancel, which changes nothing. A value the page refuses is explained under its field.

Actions that are not settings, such as signing every member out, stay on the card and ask you to confirm first.

To You need
See the Settings menu item, its tabs and every card settings.view
See Edit on a card, open its edit page, and Regenerate the install token settings.edit
Sign out everyone, Revoke all keys, Expire every password now the Admin role
See Open in Audit Trail on the Recent settings changes card audit.view

The default Regular Users role has no settings.view, so its members don’t see Settings. See Roles & permissions.

Your organisation’s Name, how many Admins it has (active members holding the Admin role), and the date it was Registered (hover over it to see the time in UTC). The name cannot be changed, so the card has no Edit button.

How much of each account limit your organisation uses. It is read-only: contact us to change a limit.

The last 20 changes to this organisation’s settings, newest first: when (in your timezone, named in the column header), who (System when no person did it), and what, with each changed setting under it, old → new. No settings changes recorded yet. when there are none.

It lists:

  • each settings save, one line per setting that changed. A save that changes nothing is not listed;
  • a regenerated install token, and replaced install tokens stopped (Stop accepting it now);
  • an SSO domain added, changed or removed;
  • every member signed out, every API key revoked, and every password expired;
  • the organisation’s registration, as the first entry.

Billing and account limit changes are not settings, and are not listed here: they are on the Audit page. Nor are a replaced install token’s use and refusals, which the Audit page lists by System. Anyone who can open Settings sees this card; the IP address of each change is shown only on the Audit page.

Open in Audit Trail →, for holders of audit.view, opens the Audit page filtered to the same changes, under the chip Resource: Organisation settings.

Ends every member’s session in this organisation, yours included. Last done shows when it was last used, or Never.

Sign out everyone is for Admins only. It asks first: Every member of {your organisation}, you included, is signed out of this organisation now and must sign in again. Their other organisations and API keys are not affected. Once you confirm, you are taken to the sign-in page. Every other member who has the organisation open is sent there at their next click or page load; signing in again returns them to the page they were on.

  • This organisation only. A member who belongs to other organisations stays signed in to them.
  • API keys keep working. To stop them, use the API Keys card.
  • If a member’s sign-in may have been stolen, signing everyone out here does not end it in their other organisations. Ask them to change their password: that ends every other session they have, everywhere.

Your verified domains, each Verified or Pending with its provider, and whether Restrict SSO to verified domains and Disable password login are on. Edit opens Edit Single Sign-On, where you add a domain, verify it, change its provider or remove it, and turn the two switches on or off. Adding, verifying and removing a domain take effect at once; Save saves the two switches. See Single sign-on.

Whether Require two-factor authentication is on, and Members with two-factor on, such as 3 of 5: how many of the active members who don’t sign in with SSO here have it on, so you can see who the requirement would stop before you turn it on. Members who sign in with SSO are exempt: their identity provider handles their second factor.

Edit opens the switch. While it is on, a member without two-factor authentication is sent to a set-up page at their next visit to the organisation, and can reach nothing else in it until it is on; their other organisations are not affected. To turn it on you need two-factor authentication on your own account first (unless you sign in with SSO here): Turn on two-factor authentication on your own account first, on your Profile. See Two-factor authentication.

How long a member’s password may stay in place before they must choose a new one.

Shows Means
Passwords expire after Never (the default), or 30, 60, 90, 180 or 365 days
Expired now Members whose password has expired here
Expiring within 14 days Members whose password expires here in the next 14 days
Last expired for everyone When an Admin last used Expire every password now, or Never

The counts are of active members who sign in with a password. Members who sign in with SSO have no password here and are not affected.

Edit opens Passwords expire after, a list from Never to 365 days. Turning it on or changing it gives every member at least 14 days before anything expires, so everyone sees the full countdown first (below).

Expire every password now is for Admins only. It asks first: Every member of {your organisation} who signs in with a password, you included, must choose a new one before using it again. Members who sign in with SSO are not affected. Once you confirm, you are taken straight to the page that changes your own. A member who joins later with a password chosen before that moment is asked for a new one too.

Shows Means
Live keys How many keys of this organisation are neither revoked nor expired
API keys Allowed, or Turned off for the whole organisation
Keys for SSO-managed members Whether members who must sign in with SSO may use keys: Allowed or Not allowed (the default)

Edit opens Edit API Keys:

  • Allow members to use API keys. Off: every key of this organisation stops working at once, and no key can be created. Turning it on again brings every key back: nothing is revoked.
  • Allow API keys for SSO-managed members. Members who must sign in with SSO can create and use keys only while this is on. Off, their keys stop working until it is on again; nothing is revoked. It can’t be changed while the first switch is off.

Revoke all keys, for Admins only, revokes every live key of the organisation, for good, after asking: Revoke all {N} live API keys of this organisation? Everything that uses them stops working at once. It is disabled when there are none. Each member’s keys, with their own Revoke, are under Organisation → Users. See Authentication and keys.

How agents enrol, authenticate and are archived for this organisation:

  • Install token, with a Copy button: the token in your agent install command. See installation.
  • Require approval for new servers: On or Off. On, a newly enrolled server waits in Pending until someone approves it.
  • Require approval for new custom metrics: On or Off. On, a metric key you haven’t declared arrives pending and stores nothing until someone approves it. See new metric keys.
  • Archive servers unseen for: how many days without a word from a server’s agent before WatchTower15 archives it, 7 days by default. See archived servers.

Edit opens Edit Server Monitoring: the two approval switches, and Archive servers unseen for the last as a slider from 2 to 30 days, the number of days shown beside it. Drag it, click the track, or use the arrow keys to move it a day at a time.

Regenerate, with settings.edit, makes a new install token, and first asks how long the current one keeps working:

  • 7 days (recommended): time for your automation to move to the new token. The card shows anything still using the old one.
  • 24 hours.
  • Stop it now: for a token that leaked. Anything using it is refused at once, and so is any older token still accepted.

Until its time is up, the replaced token still enrolls servers, runs the installer’s pre-install check and archives servers at teardown, as the current token does. Servers already enrolled keep reporting either way. Cancel keeps the token as it was. After regenerating, update every install command, image, Terraform variable and host that holds the old token: see teardown automation.

Under the token, the card shows what still uses a replaced token:

  • The previous token still works until …, one for each replaced token still accepted, with when it was replaced: Not used since it was replaced, or how many requests used it, the last one’s time, its host (hostname and supplier ID) and what for: to enrol a server, for an install’s pre-install check, or to archive a server at teardown. Stop accepting it now, with settings.edit, ends every replaced token’s time at once, after asking: anything still using one is refused from then on. It cannot be undone.
  • A replaced token was refused …: the latest refusal of a replaced token in the last 7 days, how many times it was refused, the last one’s time, host and purpose, and when the token stopped working.

A replaced token is refused, once its time is up, with a sentence that says when, and the installer and the agent show it as it comes: This install token was replaced on 30 Oct 2026 14:15 UTC and stopped working on 6 Nov 2026 14:15 UTC. Use your organisation’s current token, from the Monitoring tab of Organisation Settings. A token replaced before this feature existed is refused with Invalid organisation token., as any unknown token is.

Every Admin of the organisation is emailed:

  • A replaced install token is still in use: the first time a replaced token is used, once per token, with the host, what for, and when the token stops working;
  • A replaced install token was refused: the first time one is refused after its time is up, then at most once a day while it is still being sent;
  • The install token was regenerated and Replaced install tokens stopped: each time someone does either, naming who (their name and email address), when, and from which IP address. The Admin who did it gets the email too.

If an organisation you belong to sets a password expiry, this is what you see. A password is yours, not the organisation’s: one change satisfies every organisation you belong to.

  • The countdown. From 14 days before your password expires, every page shows Your password expires in N days. Change password (today on the last day), shown as a warning for the last 3 days. Change password opens the Authentication tab of your Profile. Close it with × and it stays hidden until your next browser session, or until the expiry date changes.
  • On your Profile. The Change password card, on the Profile’s Authentication tab, reads Last changed 2 Aug 2026 · Expires on 31 Oct 2026, required by Acme Hosting: the earliest expiry across your organisations, and the organisation that sets it.
  • When it expires, you stay signed in, but the organisation’s pages are replaced by Your password has expired, which says why: the organisation asks for a new password every so many days, or an Admin asked every member for one on a given date. Enter your current password and a new one, then Change password: you go back to the page you were on. Forgot your current password? signs you out and opens the password reset; Sign out signs you out.
  • Only that organisation asks. An organisation without an expiry, or whose expiry you haven’t reached, keeps working as before.
  • Your new password can’t be your current one or any of the three before it: You have used this password recently. Choose a different one. The same applies to a password reset.
  • SSO. If you must sign in with single sign-on, in this or any organisation you belong to, you have no password in use and are never asked.
  • Two-factor next. If the organisation also requires two-factor authentication and you haven’t set it up, you are asked for it after the new password.

API keys are not passwords: they keep working while your password is expired.