Cannot say for sure about a 2960, but I recall the 3750 had ASIC stats that would showed queued frames/packets per CoS or ToS marking. (BTW, any time frames/packets are queued, even one, you have congestion, but it's not always detrimental to applications. I.e. some often is to be expected.)
"Extreme" congestion might be detected by monitoring the drop count, as this indicates interface congestion that overflows the egress queue. (Here too, this might not be detrimental to the application.)
BTW, Reza mentions monitoring bandwidth utilization, but this often doesn't well reflect actual congestion. For example, consider ingress of 100 Mbps going out a 100 Mbps egress port. Utilization, ideally, would show 100% utilization, but there's no congestion at all. Conversely, multiple 100 Mbps ingress streams, using TCP, hitting a 100 Mbps egress port might actually show it with a low, or even very low, utilization as TCP bursts force TCP into congestion avoidance or slow start. The latter, though, will usually show a high drop rate on the egress interface.
Another problem with "typical" bandwidth utilization monitoring, especially on the usual 5 minute measurement cycle (as also mentioned by Reza), compared to the service needs of some traffic, like the VoIP you mentioned, it's way, way (way) too long an interval (even Cisco's minimal interface measurement intervals of 30 seconds is, way, way too long).
So another approach, is some form of active SLA testing and monitoring. For VoIP, for example, you might want re-occurring SLA tests that record MOS results.
Something else to keep in mind, when doing QoS, you want results per QoS class, simple interface bandwidth monitoring doesn't really help.
For example, over a decade ago, I designed, and monitored QoS for Americas (i.e. all of North and South America) operations. A fairly large site in Brazil saturated (i.e. 100% utilization, constantly) two E3s all day, during business hours. We had about anything you could think of running across those links, such as VoIP, video conferencing, video streaming, web apps, SAP apps, server file and database access usage, email sync, and data and/or database backups. All those, met their SLAs using QoS, which made it possible.
The importance of QoS was shown to Americas management in one instance when one of our HQ WAN routers rebooted itself, overnight, but dropped all its QoS settings. The next morning, the lead WAN engineer said his phone was lit like a Christmas tree with calls complaining about the network performance at all our branches. He found the missing QoS, reapplied it, and his phone went silent.
In another instance, we had global network meetings about twice a year. Our EMEA and Asia peers complained they kept buying and buying, and buying, more WAN bandwidth, but users continued to complain about network performance. They noticed that in the Americas, we had very little WAN bandwidth growth, and not anywhere near the same level of user network performance complaints and they wondered why. (BTW, our WAN link bandwidths were often, for the same remote site sizes, smaller than our peers used.) I told them, regionally we use QoS, but I noticed they didn't. (Of course, they didn't believe QoS could really make that huge of a difference. [The Americas WAN network engineer, above, didn't think so either, until the above incident.])
