You could tail the log file:

tail -20 /var/log/jamf.log

As for what you're seeing in inventory, it's showing you the status of the computer as of its last report (ie, before the policy ran). It's possible there are certificate issues on the computer, for example, and it doesn't trust the JSS.

As a first step, I would take a look at the log file as JPDyson recommends. That will give you some idea of what's happening. There are timestamps for each entry in the log, so you should be able to see when the current policy began executing.

The jamf binary may have gotten stuck in a loop or otherwise is not exiting out of the last policy run. Its rare, but it can happen. We've seen it on occasion on some of our Macs. That would explain why it hasn't checked in or submitted inventory recently, since I don't think it can't do that until it completes the current running policies.
You could try killing all the running jamf processes on the Mac while ssh'd into it, but you may of course be killing something genuine, so be careful with that. If you do, they'll respawn once the binary gets called to do its next scheduled check-in.
Also, has the Mac been rebooted recently? Do uptime on it while ssh'd to see how long its been since last reboot.

Thanks to both of you. I will check out the log as you instructed.

I forgot to mention that part of the policy is to Update Inventory after it's run. That being said, shouldn't the computer have updated the JSS? the policy ran last night.

Yes, the Mac was rebooted yesterday, before the policy was supposed to be executed.

Since the inventory update happens at the very end of the policy run and then uploads all the data to the JSS, if it doesn't get to that stage, for example if it got stuck on gathering inventory or closing down the policy install, etc, you'll never get an updated inventory in your JSS. Another possibility is that the Mac had trouble uploading the log to the JSS. If that happens, the jamf binary will store the policy log locally and attempt to upload it again the next time it connects up.

Back in an older version of Casper there was a bug that JAMF fixed where certain special characters would cause the log to not get uploaded into the JSS. This resulted in the policy executing again and again and storing another log locally on the Mac. Each time the Mac would check in it attempted to upload the ever growing list of logs, to the point that it would cause the fans to blow like crazy as it worked real hard to upload those logs, but couldn't. The only recourse was to blow away or move the logs from the folder.
I'm not saying that's happening here (unless you happen to be running a very out of date version of Casper Suite on your JSS. You aren't are you?) I'm just illustrating how sometimes things don't go as planned and need a kick in the pants to get them going again.

If the Mac rebooted prior to the policy run that doesn't mean much. If the binary is stuck running a policy that won't shut down you may need to kill it or reboot the Mac again.

Thanks for your thorough explanation.

We are running 8.63.

I'll try rebooting the machine again and see if that helps.

Thanks again for your input, both of you. :)

And another "test and get yourself to 8.71 ASAP" comment from me ;-)