Microsoft Teams Call health shows information from the meeting you are actually using. It can help you match interrupted audio, poor outgoing video or delayed responses with the relevant session measurements. A separate speed test is useful context, but it cannot replace that call’s evidence.
Open the panel while the problem is happening, record the symptom and read the metric labels before interpreting a number. A low bitrate is not automatically a fault, and a Teams send limit is not the speed of your internet plan. For planning rather than incident investigation, use the Teams bandwidth requirements guide.
Open Call health during the meeting
Microsoft’s Call health instructions show the route through the meeting’s More actions menu, then Settings and Call health. The documented view includes network, audio, screen-sharing and outgoing-video information and updates periodically. Use the current controls available in your client; do not assume every mobile, web or managed configuration exposes identical options.
Write down the approximate incident time and which direction is affected. “I hear them clearly, but they hear gaps in my voice” is more specific than “Teams is laggy.” Ask one participant to describe what they see or hear, without assuming their connection is the same as yours.
Read the label, unit and direction together
| Reading | Useful interpretation question |
|---|---|
| Round-trip time | What endpoints and call type does this reading describe? |
| Sent or received bitrate | Is this the media being sent or received, rather than spare plan capacity? |
| Received jitter or loss | Did it change during the interruption in this stream? |
| Frame rate or resolution | What content and device workload were present? |
Microsoft distinguishes round-trip scope between group and one-to-one calls. It also explicitly says Teams send/receive limits are not your ISP speed limit. Keep those distinctions with any screenshot. Comparing a session media rate with a headline broadband rate as if both meant maximum capacity can produce a misleading conclusion.
Do not apply one number as a verdict on the whole meeting. A panel can summarize a period while you experienced a brief event, and the displayed audio and video streams have different jobs. Read any typical-value guidance in its documented context rather than inventing a universal pass mark for every client and meeting.
Collect an observation that someone else can use
- Name the symptom. Identify outgoing speech, incoming speech, your camera, incoming video or shared content.
- Note the activity. Record whether you were speaking, sharing a static document, playing a clip or changing the meeting layout.
- Record the relevant readings. Keep the label, unit and send/receive direction. Write “not available” for missing fields.
- Watch recovery. Note whether the panel and symptom return to their ordinary pattern without a change.
- Choose one next comparison. Pause your own optional transfer, try a supported wired connection or reduce one avoidable device workload.
This is an observation plan, not a measured benchmark from this article. Avoid changing the router, camera settings and network connection together. If the symptom disappears after several changes, you will not know which comparison was informative.
Separate capacity from the current session
Microsoft’s network preparation guidance treats bandwidth and network quality in the context of Teams usage. Requirements and traffic can vary with the meeting activity. A home user should not copy enterprise policy or firewall changes simply because those appear in the same planning reference.
After the call, run an internet speed test as a separate baseline and record download and upload. Use the video-call capacity check to compare the selected reference profile with the available capacity, reading its assumptions. Neither result is a replay of the earlier Teams call or a measurement of its exact media path.
If the interruption consistently appears during backups or downloads, compare quiet use with the normal busy condition. Run the idle-versus-loaded latency check separately from an important meeting, because it deliberately adds traffic. Then see whether the original Teams symptom follows the same pattern.
What a low video rate can leave unanswered
Ask what was being sent and whether the picture was actually impaired. A still scene, changed layout or device limitation can make a simple “higher is always better” reading unhelpful. Do not infer the exact cause from one media-rate snapshot. Compare the same action and note both the visible outcome and the panel.
Likewise, missing a field does not mean its value is zero. Preserve the absence in your notes. If a screenshot includes participant names or meeting details, crop it to the necessary diagnostic information before sharing it through the intended support channel.
Escalate with a short, consistent account
Give IT or support the time and timezone, client/version, connection type, affected direction, relevant labeled readings and one comparison. State whether others reported the same event and whether your local symptom continued after it. That helps distinguish an individual-client investigation from a wider incident without assigning blame prematurely.
Keep using the call’s own evidence when following up. A fast download later is compatible with a real earlier interruption. The useful outcome is a repeatable description of the failing task, not a collection of unrelated large speed numbers.