Loading page
A quiet screen does not tell you everything about a conversation. Steam’s Do Not Disturb controls chat, invite and request notifications. To understand a missing alert, distinguish the state you selected from the alert you noticed and the message or request actually visible in your own account. These are different observations, not automatic evidence that someone ignored you or that communication failed.
| Item | What to record | What it does not prove |
|---|---|---|
| Selected state | Your actual current choice | Another person’s intention |
| Alert | What you noticed at the time | Complete delivery history |
| Content | Message or request you can actually identify | A reading receipt |
Use only your own observations. Do not manufacture a message exchange or ask another person to send repeated requests merely to populate the table. Leave an unknown point unknown until you have an appropriate observation.
Write whether you expected a chat alert, an invitation notice or a request notice. “Nothing arrived” is ambiguous if you mean only that no visible notification appeared. Note the relevant session context without copying private conversation into the troubleshooting record.
Avoid using that uncertainty to explain another person’s behaviour. A missing alert on your screen says nothing by itself about whether someone read your words, chose not to reply or used a particular communication state.
Look at the current state in your own client and compare it with what you intended. If you do not know what was selected when the expected alert would have appeared, record that limitation. A current choice is not automatically a historical record.
The Steam overlay guide concerns another visible-interface question. If the issue is that an interface is not opening, document it separately instead of treating every missing visual element as the same notification problem.
If a message is identifiable in your own account, describe that observation separately from whether you noticed an alert. Do not convert it into a claim that every earlier message was delivered or that its sender knows you viewed it.
The chat-filter preferences guide addresses how content is presented, not proof of alert delivery. A word-display question and a notification question can coexist, but they need their own descriptions before you choose what to examine.
An absence of alerts is not, by itself, evidence that the account has been taken over or that another user blocked you. If you have a separate concrete account-access concern, describe that concern using its actual evidence rather than extending the notification symptom.
The authorised-devices guide concerns account-device management. It is not a required response to every quiet chat session. Keep the task narrow and avoid unrelated account changes just to produce a feeling of certainty.
A useful conclusion might be that a request is visible but no alert was noticed while the intended quiet state was selected. Another might be that the historical state is unknown, so the earlier alert cannot be assessed confidently. Neither conclusion needs an accusation or a promise about delivery.
Prepare support evidence without secrets if a specific issue remains. Keep private content out of the note. The worksheet does not disconnect an account, erase history or perform a message test; it separates observations so the next question is actually about notifications.
Sources checked on 3 November 2026. Verify available settings in your current client; the tables give hypothetical examples for your own checks.
What you should know before you begin.
No. Keep the alert observation separate from any blocking question or another person’s intention.
Do not turn visible content in your own account into a claim about what another person knows.
Not on that symptom alone. A separate concrete security concern deserves its own evidence and process.
