Support & Messages

There are two different kinds of “help” in SeqDesk, and they go to two different places.

• A question about your data or your sequencing order — a sample that looks wrong, a run you were expecting, a metadata field you do not understand — goes to your sequencing facility, through the built-in ticket system described below. The facility admins of your installation read these.
• A problem with SeqDesk itself — the app will not start, an upgrade broke something, a page throws — goes to the SeqDesk project through the public support board. See Reporting a SeqDesk problem.

Sending an app bug to your facility admin as a ticket is not wrong, but they will need the same diagnostics listed further down, so collect them either way.

The ticket system

Tickets live at /messages and are visible to the researcher who opened them and to every facility admin. There is no per-admin assignment; the queue is shared.

Creating a ticket

You can only reference sequencing orders and studies you are allowed to see. If your installation has department sharing enabled, that includes orders belonging to others in your department. A reference you are not entitled to is rejected with Selected order could not be found — the same message as a genuinely missing order, deliberately, so the endpoint does not confirm that a record exists.

Statuses

Two transitions happen automatically when a message is posted:

• An admin replying to an OPEN ticket moves it to IN_PROGRESS.
• A researcher replying to a RESOLVED ticket reopens it to OPEN.

Who can change what

Replying

Open a ticket to see the thread. Messages render as chat bubbles — yours on the right, the other party’s on the left, with a staff badge on admin messages. Type at the bottom and send.

Read state is tracked per side: opening a ticket stamps userReadAt for a researcher and adminReadAt for an admin. A ticket counts as unread for you when the other side posted after your last read, which is what drives the unread dot in the list.

Finding a ticket

The list is the same page for both roles, with the same tools. Above it sit three counters: Open (OPEN plus IN_PROGRESS), Unread, and High priority (HIGH plus URGENT).

• Search matches the subject, the referenced order number or name, the referenced study title, and the ticket owner’s first name, last name, or email.
• Status filter narrows to one status.
• Sort by updated, subject, status, message count, or priority, ascending or descending.

Researchers only ever see their own tickets in that list; admins see all of them.

Choosing a priority

Priority is a signal to your facility, not an SLA. Use it honestly.

Admins can and do re-prioritise tickets.

Other places to ask

Tickets are not the only channel:

• Help & Guide (/help) — an in-app orientation page covering the sequencing order → study → analysis → publishing flow, who does what, and where each task lives. It links straight to Support for anything unclear.
• Entity notes — sequencing orders and studies each have a notes panel. Use it when the discussion belongs to that record rather than to a support conversation: a sample anomaly, a metadata gap, a decision about which assembly to keep. The note stays attached to the record and is visible to everyone who can see it.

Rule of thumb: if the answer would be useful to whoever opens that study next year, it belongs in a note. If it is a request aimed at a person, it belongs in a ticket.

Email notifications

At Settings (/settings) you can maintain your profile — first name, last name, phone number, institution — and two independent Email Notifications toggles:

• Sequencing Orders — sequencing order submissions and facility status updates.
• Support — support ticket replies.

Both only appear when the installation has outbound email configured. Your email address is read-only; ask an admin to change it.

Reporting a SeqDesk problem

A report that lets someone reproduce the failure gets fixed. A report that says “it doesn’t work” does not. Open a public SeqDesk support thread with the following. The thread and our response will be visible to everyone, so remove credentials, patient or sample data, private URLs, and other sensitive information first. Contributors who prefer the development tracker can instead open a GitHub issue .

1. Versions

• The app version. GET /api/version on your installation returns {"version":"1.1.125"}, and seqdesk doctor prints the installed package.json version too.
• The launcher version — the Version line at the top of the doctor output.
• Node.js (node --version), your OS and version, and whether PostgreSQL is the installer’s private cluster or one you manage.

2. seqdesk doctor output

This is the single most useful attachment. From the install directory:

cd ~/seqdesk
npx -y seqdesk@latest doctor

Or from anywhere, naming the directory the installer reported:

npx -y seqdesk@latest doctor --dir /opt/seqdesk --url http://127.0.0.1:8000

It prints a header, one line per check, and a summary:

SeqDesk doctor
  Version                  1.1.125
  Directory                /opt/seqdesk
  URL                      http://127.0.0.1:8000

Checks
  Install directory        /opt/seqdesk
  package.json             seqdesk@1.1.125
  settings.json            parseable
  start.sh                 executable
  node_modules             present
  .next/static             present
  runtime.databaseUrl      127.0.0.1:5432/seqdesk
  PostgreSQL TCP           127.0.0.1:5432 reachable
  warning runtime.directUrl - missing; databaseUrl will be used as fallback
  runtime.nextAuthUrl      http://127.0.0.1:8000
  runtime.nextAuthSecret   set
  HTTP /api/auth/providers credentials auth available
  HTTP /api/setup/status   database configured

Summary
  Passed                   11
  Warnings                 1
  Errors                   0

Failing checks are printed as error <name> - <detail> with the suggested next step indented underneath on an -> line. Paste the whole output, warnings included — the exact wording of a remediation line identifies which check produced it. --json gives a machine-readable version of the same result, and the command exits non-zero when any check failed.

Useful flags: --dir / -d for the install directory (defaults to the current directory), --url / -u for the running app, --timeout-ms to raise the 5-second timeout on a slow database, --json, and --help.

See seqdesk doctor for what every individual check means.

3. The install log

If the problem happened during installation or an upgrade, attach the install log. Its path is $SEQDESK_LOG; when you do not set that variable the installer creates one under $TMPDIR (usually /tmp) named seqdesk-install-<date>-<random>.log, created mode 600. Set it explicitly if you want a predictable path:

SEQDESK_LOG=/tmp/seqdesk-install.log curl -fsSL https://seqdesk.org/install.sh | bash

Re-running the installer with --verbose promotes the diagnostic detail that otherwise goes only to that log onto the terminal.

4. What you did and what happened

The URL or screen, the exact steps, the exact error text (copied, not paraphrased), what you expected instead, and whether it reproduces. For a failed pipeline run, add the run number and logs/pipeline.err from the run folder. For a failed ENA submission, add the submission id and the step timeline — see Troubleshooting ENA.

Before you file

Several problems have documented fixes already:

• Common installation problems — a symptom-to-fix table.
• Troubleshooting ENA — every error the submission paths produce.
• FAQ.
• Known limitations — things that are working as designed.