Diagnostics And Logs

BareBones Ticketing has two read-only status pages inside the application. This page covers both, the deployment logs behind them, and what to strip out of a log excerpt before it leaves your hands.

There are also two anonymous health routes for monitoring tools, covered below.

The two health endpoints

Two routes exist for monitoring. Both answer without signing in, both return a small JSON body of the form {"status":"Healthy"}, and both are marked Cache-Control: no-store.

Route	What it proves	What it does not prove
`/health/live`	The web process is up and answering HTTP.	Anything about the database, mail, the outbox, or whether work can be done.
`/health/ready`	The process is up and it can open a connection to its configured database, checked with a three-second timeout.	That the product is correct, that mail is deliverable, or that background work is keeping up.

Point a monitor at /health/ready. It is the one that fails when the product cannot serve, and it is what the Linux container healthcheck uses. Use /health/live to tell "the process died" apart from "the process is up but its database is not reachable" — the distinction that decides whether you restart the application or go and look at the database.

Neither route is a statement that the product works. Healthy means the process answered and, for readiness, that the database accepted a connection. It says nothing about whether tickets are being routed, mail is going out, or the SLA timer is running. System Diagnostics below is where those live.

Do not substitute any other page for these. A page returning HTTP 200 tells you the web server answered, nothing more.

There is also /admin/ping, an older bare liveness route restricted to SystemAdmin. The health routes above supersede it for monitoring, because a monitor should not need an administrator identity.

System Diagnostics

System Diagnostics shows current and recent status for six components. It is read-only: it does not repair, retry, alert, or change anything, and reading it does not record an audit event.

You need the SystemAdmin role. Ordinary reads do not need a step-up.

Select Settings in the main navigation. It is visible to SystemAdmin.
Open the System Diagnostics destination card. The cards on Admin Settings are hidden until you complete a step-up, even though diagnostics itself does not require one.

If you are already authorized, go to /admin/system directly instead.
Read Overall, Evidence scope, and Current evidence snapshot before opening any component.
Confirm the generation time, environment, application version, evidence mode, and history window shown at the top. Everything below is relative to these.
Choose the smallest history window that answers your question: 24h, 7 days, 30 days, or 90 days. A wider window costs more to produce and does not scan anything new.
Open the component you need: Database, Product license, Directory, Mail delivery, Background jobs, or Storage.
Use History, Source trace, and Investigation on that component for freshness, the facts it is based on, what it excluded, and which workspace owns the follow-up.
Select Refresh diagnostics once if the evidence is stale. Refresh re-reads; it does not fix.

Reading the result honestly

Current means it was generated at the time shown. It does not mean every dependency was probed just now.
A window with no signals can mean there was nothing to record, not that the component was healthy.
Needs review points at a follow-up. It is not a diagnosis.
Informational is context. On its own it is not an incident.
Deferred and unavailable evidence was not measured. Do not report it as if it was.
The public address shown is the configured value. Nothing tested Domain Name System (DNS), Transport Layer Security (TLS), the proxy, or whether anyone outside can reach it.
Attestation is a summary of this evidence. It is not a release approval, a compliance score, or a security verdict.

The Database component reports connectivity, migration state, and counts of tenants, departments, active users, tickets, audit rows, and outbox rows. It does not check project routing, assignment mappings, role staffing, or Customer Portal single sign-on (SSO) handoffs. A green database tile says nothing about any of those. Review them in their own workspaces.

Do not change a setting to make a tile look better.

Database Connection

Database Connection at /admin/database-connection shows PostgreSQL connection status. It needs SystemAdmin and a recent step-up before it renders any detail.

Complete the step-up, then open Database Connection.
Under Review active PostgreSQL connectivity, read the provider, where the configuration came from, whether the server is reachable, and when the reading was generated.
Select Review System Diagnostics if you need the wider picture.

It is read-only. It does not show the connection string or password, switch providers, edit configuration, browse the schema, run SQL, apply migrations, or take a backup.

The connection it reports belongs to the restricted runtime database identity the package created. That identity is not the setup login, not the database owner, and not a superuser.

Service and container logs

Application authority is not host authority. Being SystemAdmin in the product does not entitle you to the host, the database server, the proxy, or the secret store. Get that approval separately.

On Windows, service start problems are in the Windows Event Viewer Application and System logs. Installer failures are recorded at C:\ProgramData\BareBonesTicketing\install\last-install-failure.json.

On Linux, from the package root:

docker compose logs web

docker compose logs db

The db command works only where you run the database container that ships with the package. If this installation points at an external PostgreSQL server, there is no db container and the command returns nothing. That is not a fault. Read the database server's own logs on its host instead.

Narrow to a time range and a component before you open host-level evidence, and retrieve only what you need to explain the symptom.

What the application logs deliberately

Four seams write structured entries carrying a stable event identifier, so they can be searched for rather than read past:

a ticket create that was rolled back;
a workflow, service, or status change refused because it would strand live tickets;
outbox failures — no handler, a retry, a permanent failure, a handler exception, or a failed processing cycle;
SLA timer activity — a warning, a breach, or a failed timer cycle.

These are chosen as the places where something silently going wrong would otherwise reach you as a customer complaint. They are not a full trace of what the product did.

Log entries are deliberately thin. They carry operation names, outcome and reason codes, component identity, internal identifiers, exception class names, timestamps and counts. They do not carry ticket titles or descriptions, comment text, custom-field values, attachment names, recipient lists, email addresses, outbox payloads, raw exception messages or stacks, or anything secret. That is deliberate: an operator reading logs should not thereby read the tickets.

The consequence is that a log entry tells you what failed and why, and rarely which record it was about in business terms. Follow the identifier into the product, or into the audit history, rather than expecting the log line to explain itself. Logs are also not audit evidence — see Audit and evidence.

Keep the original where it is, under its existing access controls. Copy out only the lines that explain the symptom, then remove all of the following from the copy:

passwords, licence keys, application programming interface (API) keys, tokens, cookies, private keys, and connection strings;
environment file contents, secret-store values, and request or response bodies;
personal data, email addresses, ticket text, comments, custom-field answers, and attachment names;
project names, descriptions, staffing, mappings, and routing outcomes, unless the audience is approved for them;
private hostnames, internal addresses, and private URLs;
raw Security Assertion Markup Language (SAML) assertions, Lightweight Directory Access Protocol (LDAP) bind detail, mail bodies, and stack traces containing protected values;
Customer Portal SSO handoff bodies, signatures, shared secrets, nonces, subject hashes, and grant data.

Keep the timestamps, the component, the severity, a correlation identifier, and a short error classification. Those are what the next person needs.

Record who sanitized the copy and where an authorized investigator can read the original. Do not paste a raw log into email, chat, an issue, or a customer message.

If a secret has already been exposed, stop copying it, tell the security owner, and follow the rotation procedure. Do not repeat the value in the notification.

After an error page

When the application sends you to /Error, it shows a Support code and the Coordinated Universal Time (UTC) at which the error appeared. Those two values correlate the event. They do not tell you whether the action you were performing committed.

Do not repeat the action, and do not assume nothing changed.
Record the support code, the shown-at UTC time, the environment, the version, the workspace, and what you were trying to do. Not the values you typed.
If the page only reads data — a list, a status view, a diagnostics snapshot — you may use Refresh page once. That is a fresh read, not proof the earlier action rolled back.
If the action could have created, changed, deleted, imported, sent mail, or called another system, do not refresh. Select Go home and reopen the workspace normally.
Find out what actually happened: search for the record that may have been created, reopen the affected record and read its current values, check the queue or import run or outbox, and where you are authorized, check the audit entry.
If it completed, carry on from there. If nothing changed and the action is safe to repeat, make one deliberate attempt once you know why it failed. If you cannot tell, stop and escalate.