Mac menu bar app shows the wrong status? Verify it

If a Mac menu bar app shows the wrong status, do not reinstall it yet. Write down the displayed value and time, identify what the value measures, confirm the target device or session, make one controlled change, and test the output. A correct value for the wrong target still looks wrong.

Disclosure: I build TeenyApps, including TeenyScreeny and TeenyMute. My bias is toward small native menu bar utilities. My rule is still conservative: when the menu bar and Apple's settings disagree, use Apple's setting as the source of truth and use the utility to shorten the next check.

Short answer: verify the source, target, write, readback, and outcome in that order. This separates a stale display from a wrong device, a failed write, and a correct control that affects a different layer.

Quick triage table

Record the evidence chain before changing settings

A status value has a source and a target. A control adds two more checks: whether the write succeeded and whether the app read the new state back. The final check is the outcome you actually care about.

System Settings is often part of this record, but there is no single Apple screen that owns every status. Sound input identifies a microphone. Apple Screen Time reports app and website activity. Activity Monitor identifies process load. Login Items & Extensions records startup authorization. Match the Apple view to the claim you are checking.

Screeny 1.0.2 counts keyboard activity without Accessibility

Screen time is easy to misread because active time is not the same as awake time. A Mac can be awake while you are away, and a tracker should stop during sleep, lock, or another inactive login session.

The current TeenyScreeny 1.0.2 source asks Core Graphics for the seconds since any keyboard, mouse, or tablet input. That system idle clock is authoritative when it returns a valid value and does not require Accessibility permission. A local mouse-event timestamp remains as a fallback. This replaced the older permission-dependent keyboard monitor described by the previous version of this article.

For a clean test, confirm version 1.0.2 or later, confirm tracking is not paused, keep a normal idle timeout, and type for two minutes without moving the mouse. Then lock the screen for 30 seconds. The counter should move during typing and stop while the screen or session is inactive. Change the timeout only after this test passes.

The deeper Screeny guides are Mac screen time not counting keyboard activity and Mac screen time menu bar counter.

When a microphone status looks wrong

Microphone status has more layers than people expect. A meeting app can say you are unmuted while a Mac-level mute utility keeps the selected input quiet. The orange microphone indicator can show that an app has microphone access even if that app is receiving silence. Those are different facts.

TeenyMute works at the selected input-device layer. Its source resolves a pinned device by persistent UID when that device is present. If the pinned device is missing, it falls back to the Mac's default input. The app also listens for default-input and device-list changes. A dock reconnect can therefore change the target even when the menu bar remains visible.

Mute support varies by device. TeenyMute uses Core Audio's input mute property when the selected device exposes a settable control. Otherwise it writes input volume. After either write, it refreshes the mute state and reports success only when the readback matches the requested state. That proves the target control changed, but a short recording is still needed to prove the meeting or recording app uses that same input.

The deeper Mute guides are Mac microphone mute not working with external mic and Mac microphone input device checklist.

When startup status does not stick

Startup state is a separate problem from live state. A utility can work perfectly after you open it manually and still fail the first-minute test because it did not launch at login.

For a screen-time counter, that means the first work block may be missing. For a microphone mute app, it means the expected muted, unmuted, or last-state choice may never be applied. For any always-on utility, it means the menu bar signal cannot be trusted until the app is actually running.

Run one clean restart test. Check Login Items & Extensions before opening your work apps. Confirm the menu bar item is visible. Confirm the value or state matches the app's startup setting. If it does not, disable and re-enable the login item once, then retest. Avoid changing permissions, devices, and startup settings in the same pass.

The broader startup rulebook is Mac login items checklist for menu bar utilities.

A six-line wrong-status record

1. Value and time: write down exactly what the menu bar shows and when.
2. Version and mode: record the app version, pause state, idle mode, or startup mode.
3. Source: name the API, saved setting, or system report behind the value when the app documents it.
4. Target: name the device, session, process, or date range the value describes.
5. Readback: make one change and confirm the app reads the requested state back.
6. Outcome: repeat one observable test such as typing, locking the screen, or making a local recording.

If the readback passes but the outcome fails, the wrong target is the leading suspect. If the write fails, stay at the control layer. If the displayed value is stale, relaunch once and repeat the same test before resetting permissions or preferences.

Common questions

Why does a Mac menu bar app show the wrong status?

The displayed value may describe a different source, device, time window, or control layer than the result you are checking. Record the value, identify its target, make one change, confirm the readback, and test the real outcome.

Should I trust the menu bar or System Settings?

Use the control that owns the state you need to verify. Sound input identifies the selected microphone, Apple Screen Time reports app and website activity, and Activity Monitor identifies process load. A menu bar utility may measure a narrower layer.

What should I check first when a mic mute status looks wrong?

Confirm the meeting app input, the Mac Sound input, and the input device targeted by the mute utility. Then toggle once, confirm the utility reads the new state back, and record a short local sample.

Sources checked

• TeenyScreeny facts were checked against the TeenyScreeny homepage, the live 1.0.2 appcast, and local Swift source for the system idle clock, mouse fallback, idle timeout, sleep, lock, and session handling.
• TeenyMute facts were checked against the TeenyMute homepage and local Swift source for selected input devices, persistent device UIDs, default-device fallback, Core Audio mute support, input-volume fallback, and success-gated readback.
• Apple Developer: seconds since the last keyboard, mouse, or tablet input event.
• Apple Support: Get started with Screen Time on Mac.
• Apple Support: Control access to the microphone on Mac.
• Apple Support: Change the sound input settings on Mac.
• Apple Support: If you cannot record from an external source on Mac.
• Apple Support: Change Login Items & Extensions settings on Mac.
• Apple Support: Use Control Center on Mac.