What fires when a crisis is detected
Crisis is the one thing in the console that pages people in real time. This is the whole path, end to end, so you know exactly what happens between a student typing a sentence and your phone buzzing.
Understanding this path matters even on quiet days. When a crisis does fire, you do not want to be working out how the system behaves for the first time. Knowing in advance what is automatic and what depends on you is what lets you move straight to the human follow-through.
How a crisis is detected
When a student writes a help message, the text is checked against a list of crisis signalsPhrases that indicate danger to the student themselves or to others, used to flag a request as a crisis. (phrases that indicate danger to themselves or others). That check runs twice: once in the student app as they type, and again on our server when they submit.
The server has the final word. It can only ever upgrade a request to crisis, never downgrade one. So if a student's app missed a signal, or someone tried to mark a genuine crisis as "normal", the server still catches it and escalates.
The reason for two checks is resilience. The in-app check is fast and gives the student immediate resources, but it runs on a device you do not control and could be out of date or interfered with. The server check is the one that decides, so a crisis is never dependent on the student's app behaving correctly.
Both checks run on every message in a conversation, not just the first: a student who becomes distressed three replies into a routine thread about a timetable clash trips exactly the same pathway. And it is one pathway from every surface, the web app and the native mobile app alike, because both route through the same server-side handler rather than each carrying its own copy of the rules.
There is a default floor of signals every tenant gets. Your institution can add its own phrases on top, and additions are only ever additive. An admin manages those extra phrases directly in Settings, Integrations, Crisis distress signals: add campus-specific wording or local slang, and edit or remove the ones you added. The default floor stays in place underneath and can't be removed. The list is tuned to over-detect rather than miss something. That means the occasional false positive is expected and acceptable; the cost of a missed crisis is far higher than the cost of a careful look at a request that turns out to be fine.
The floor covers two intents. The phrases are deliberately specific (a verb plus a target, like "shoot up the" or "want to die") rather than lone words, so everyday sentences such as "this exam is killing me" don't trip it. It's the same on every tenant unless your institution adds to it.
See the current default signal list
Self-harm or suicide: "suicide", "suicidal", "kill myself", "killing myself", "end my life", "ending my life", "want to die", "wanna die", "better off dead", "no reason to live", "not worth living", "self harm", "self-harm", "harm myself", "hurt myself", "don't want to be here", "dont want to be here", "can't go on", "cant go on".
Acute distress or isolation: "no one to talk to", "nobody to talk to", "no one i can talk to", "don't know who else to talk to", "dont know who else to talk to", "can't cope", "cant cope", "not coping", "can't do this anymore", "cant do this anymore". These read as "I have run out of people and capacity". They are deliberately narrow so ordinary where-do-I-ask questions don't page the crisis channel, and this group will flag more non-emergencies than the list above: treat a match as a reason to look sooner, not proof of an emergency.
Threats to others (the campus or its people): "shoot up the", "shooting up the", "shoot the school", "shoot the uni", "shoot the university", "shoot the campus", "shoot the class", "attack the school", "attack the uni", "attack the university", "attack the campus", "blow up the", "blowing up the", "bomb the school", "bomb the uni", "bomb the university", "bomb the campus", "bring a gun", "bring a knife", "bring a weapon", "kill them all", "kill everyone", "kill the students", "kill the staff", "kill the teachers", "going to hurt people", "want to hurt people", "want to kill people", "plan to attack", "going to attack", "going to hurt them", "make them pay", "they will all pay", "make everyone pay".
A few entries repeat with and without an apostrophe or hyphen (for example "can't go on" and "cant go on") so a signal isn't missed on a typo. This floor is maintained by First Six and is always on: your institution can add phrases, but it can't remove or weaken these.
Who gets paged, and how
The moment a request is crisis priority, the student is shown immediate-support resources in the app, and your team is alerted. The alert goes out across every configured channel at the same time, not one-after-another:
- Email (via SendGrid) to every staff member who holds the respond-to-crisis permission, whether that comes from a built-in role or a custom one you built yourself. Selection is by permission, not by role name, so staffing crisis response through custom roles works exactly as well as using the built-in ones. Deactivated staff are excluded, and the list is narrowed to people who can actually see that student.
- Slack or Microsoft Teams, if your institution has configured a crisis webhook.
They fire in parallel on purpose. Email can silently stall in a queue and look sent when it never arrived, so the Slack or Teams path does not wait on it. Any one channel succeeding is enough to reach a human.
If every channel fails for a crisis, the server emits the loudest signal it has: a top-priority error event into our monitoring (Sentry) tagged with the request id, the institution, and how many recipients were attempted. A dedicated Sentry alert rule matches that specific event and emails our on-call address within a minute, so a human sees it even though the primary fan-out failed. The student still sees their request was received and is shown immediate-support resources regardless.
The practical takeaway: more configured channels means more independent ways to reach someone. If your institution has only email set up, a stalled email queue is the single point of failure. A Slack or Teams webhook is cheap insurance against the one path that most often fails silently.
What you see in the inbox
A crisis ticket does not wait its turn. It pins to the top of the inbox regardless of how you have sorted, with a red border and the banner Possible crisis. Please respond now.
In the ticket you also see whether the student was shown the immediate-support resources and whether they acknowledged them, with timestamps. That tells you whether they have already seen the crisis lines (000, Lifeline, Beyond Blue) or whether you should lead with them. If the student has not acknowledged the resources, opening with them is the safer first move; if they have, you can move to the human conversation sooner.
What to do
- Respond now
This is the single queue you never let sit. A crisis ticket is the one thing that overrides whatever else you were doing.
- Acknowledge the ticket
Acknowledging tells the rest of the team it is being handled, so no one duplicates the response and everyone knows it is covered.
- Follow your institution's crisis procedure
The app has already put immediate help in front of the student. Your job is the human follow-through, on your institution's terms.
By the time you see a crisis ticket, the student has been shown immediate support and your team has been paged across every channel. None of that depends on you noticing first. Your role is the follow-through, not the first response.
Common questions
A crisis ticket looks like a false positive. Do I still respond?
Yes. The list is tuned to over-detect, so some flagged requests will turn out to be fine. Treat every crisis ticket as real until you have confirmed otherwise. The cost of looking at a false positive is far lower than the cost of dismissing a real one.
What if I do not get an alert but see a crisis in the inbox?
The inbox is itself a channel: a crisis pins to the top with a red border regardless of whether a page reached your phone. If alerts are not arriving at all, that is a configuration issue worth raising, because a silent email path is exactly the failure the parallel channels exist to cover.
Can a colleague mark a crisis ticket back down to normal?
Not in a way that sticks. Priority is one-way. Automatic detection and staff-initiated escalation can both upgrade a ticket to crisis, but nothing can lower the priority again. So a genuine crisis stays a crisis even if someone tries to demote it.
Can I escalate a non-crisis ticket to crisis myself?
Yes. Institution admins, support responders, platform owners, and any custom role granted the respond-to-crisis permission all have a Mark as crisis action in the ticket drawer. It pages the built-in admin and responder roles through the same channels as auto-detection (the email fan-out doesn't yet select custom-role responders), with wording that makes clear it was a staff judgment call. Content editors don't have this action. They author content, not respond. See the limits of automated detection.
Related
The fastest answer is usually one question away.