Troubleshooting

The system usually says what happened, but not always on the screen where the symptom appeared. This table is the mapping.

Symptom	Where to look
A screen is showing demo data	Support center → System information
A server you know is not in the list	The filter-chip strip above the table, ending in "Clear all"; the search box; the saved view in use
A saved value is missing on another screen	The refresh button in that screen's toolbar
A save that did not stick at all	The notice that appears in place, beside the field
An invitation or email never arrived	Settings → Integrations and connections, the mail connection, "Send a test email"
A scheduled report never arrived	Settings → Scheduled reports → Delivery log
A format is missing from the format list	The reason is printed beside it on that same screen
One person did not get a message	The recipients step of the alert rule
A rejected sign-in	The wording of the message itself — see below

Demo data instead of real data

A source that does not answer never takes a screen down, and never shows old rows as if they were fresh. It shows demo data and says so: on the databases screen as an amber note reading "Demo data" beside the name of the unavailable source, and in system information as "unavailable — the servers page is showing demo data".

Application data and server inventory are two separate lights because they fail separately. A working calendar beside a servers page on demo data is a healthy system and one broken source.

A save that did not stick

Every write reports whether it persisted. A rejected write puts the previous value back on screen and shows a notice — it is never swallowed, and that is what separates "the save failed" from "the save worked and I am looking at another screen".

With no database, some settings screens still accept a save and mark the row "not saved to the database (offline)". That row will be gone when the server restarts. It is a notice, not a fault.

If the save did succeed and the value is still missing elsewhere, that screen read its data before the save. See Data freshness.

Mail, invitations and tickets

A failure in a secondary service does not cancel an action. A ticket that could not be opened does not cancel the window; it is recorded and shown. For diagnosis that means a missing invitation is a mail problem, not an event problem — the event exists, and it is on the calendar.

Prove the mail path with a real send, not with a successful connection. Send a test email sits beside the test button on the mail connection card, and it is the only thing that proves a message reaches a mailbox.

A scheduled report that never arrived

The delivery log holds a row per attempt, failures included, with the reason. Three patterns recur:

• No row at all — the report did not run. Check that it is enabled and that its next run time has already passed.
• A failed row — the reason is in the row. A failed run retries on the next tick; after a bounded number of attempts the schedule advances to the next occurrence anyway, so a dead mail server costs three attempts rather than wedging the schedule forever.
• A successful row with zero recipients — the group is empty, or every member was filtered out.

A schedule enabled after a long pause sends once and moves to the next occurrence. It does not replay the occurrences it missed — three identical reports landing together is not catching up, it is a fault.

A format missing from the list is not a fault: this deployment cannot produce it, and the reason is printed beside it — a server component that is not installed, or no Hebrew-capable font on the server. HTML is always available and is the only format that goes into the mail body; everything else is attached as a file.

One person did not get a message

The recipients step of an alert rule states, before you save, how many people would receive it right now — and lists anyone who could not be resolved, with their reason: not registered for any of the channels this message uses, or no phone number. A name that is not in the list will not be messaged, and that is said before the send rather than after it.

A rejected sign-in

The messages differ on purpose, and each one points at a different action:

The message	What it means
The user id was not found in Active Directory	The number typed does not exist in the domain
The password is incorrect	The id exists, the password does not match
The account is disabled in Active Directory	Account state — the infrastructure team, not the user
You signed in to the domain, but this user has no access to the system	Authentication succeeded; the user is not in the group allowed to sign in
There is currently no connection to the AD server	Transient. The sign-in screen retries on its own
Too many sign-in attempts	A temporary lockout. It is off by default and configured in Settings → Security and sign-in

What to attach to a ticket

Copy report, in the support center. It carries the version, server time, uptime, both lights, the list of configured connections, the user, their role, their permission count and the browser. That is exactly the first round of questions that would otherwise be asked over the phone. The screens themselves are described in Health checks.