Contact support, and the status page
"Contact support" beside "Help with this screen" on every admin screen, and in the user menu. The status page is public: no sign-in, its own address.
Who opens it: anybody on the team who is stuck, or who thinks something is broken. What they came to do: find out whether it is EntryWick or them — and if it is us, tell us without writing an essay. What must be true when they leave: either the status page answered it, or a message is on its way with everything needed to reply properly.
Is it us? Check the status page first
status.entrywick.com says, measured the moment you load it:
| Line | What it means |
|---|---|
| Registration and admin | The part your organizers and registrants use, and when it last answered somebody |
| API | The same, for anything built on the API |
| Scanner app | The same, for phones at a gate |
| Database | Whether the store behind all of it is answering |
| Cache and queue store | Whether the fast store behind live counters and signed-in staff is answering |
| Background work | How many jobs are waiting. A deep queue is not an outage — email and badges are just later |
| Certificates | How many custom addresses have a certificate, and how many do not |
| Backups | How long ago the last database dump was taken |
Two things worth knowing about it:
- It cannot tell you EntryWick is down. One application serves registration, the admin, the API, the scanner and that page. If the application were down, the page would not load at all — which is its own answer.
- Check-in never depends on it. A scanner already paired admits people with no signal whatever, and uploads when it has one. A red line on the status page is never a reason to stop a gate.
GET https://status.entrywick.com/status.json is the same answer for a monitor, and GET /up on any EntryWick host
answers 200 while that host is serving.
Contacting support
"Contact support" opens a short form: what it is about, and what is happening. Say what you did, what happened, and what you expected instead.
What is sent with it, shown on the page before you send:
- The organization's name and its address
- The plan you are on
- Your name and email — the reply goes to you
- The screen you pressed "Contact support" on
- Whether this is EntryWick's cloud or your own server, and which release
What is never sent: nobody's registration, nobody's contact details, no attendee's answers, and nothing from your database. Never put a password or an API key in the message; nobody at EntryWick needs one, and anybody asking for one is not us.
An organization at the white-label level that has set its own support address gets its own: the form sends there, not to EntryWick, for the same reason the help links go to their documentation.
What makes a reply fast
- The reference, not the description. A registration's reference, an event's name, a ticket, the code of a day or a group. One reference beats three paragraphs.
- When, near enough. "About 9:15 this morning" is enough to find it in the audit log.
- One person, one case. Two unrelated problems in one message get one reply and one of them forgotten.
During an event
Say so in the first line — "we are at a gate now" — and say which gate. Anything that stops people getting in is answered before anything else.
While you wait: a refused scan can be overridden by a role that may, the help desk finds anybody by name or phone, and walk-up registration registers somebody who never did and prints their ticket. None of those needs us.