The mining hardware/software will report a realtime hash rate, based upon the operation of the hardware/software.
However, the process of mining is a stochastic random process. Essentially, the job of a miner is to find a partial "hash collision" - essentially, the miner hashes the transaction data and a random nonce, and aims to find a hash as close to 000000000....00 as possible. The bitcoin/alternative network agrees a priori, what threshold counts as a "hit". The miner essentially tries random nonces, until it either gets a hit, or is told that its transaction data is stale, and needs to be refreshed.
Because, in the case of bitcoin, the network sets the target such that on average 1 "hit" is found every 10 minutes worldwide. This means that an individual miner might have to run for weeks or months to get a win and be awarded the (currently) 25 BTC reward for successfully computing a hash below target. In practice, therefore most miners operate on "pools", where a central server coordinates multiple diverse pieces of mining hardware operated by multiple individual operators. The pool operator when they receive a 25 BTC reward, then divides it up amongst the contributors.
The way the individual pool servers account for hash rate is to set a lower hash target, and count the number of "hits" each miner gets. E.g. if the main bitcoin network has target is
Because pools can only detect hashrate by the rate at which "hits" are delivered, the reported hashrate will necessarily vary by virtue of the statistical properties of a stochastic process. The degree of variation depends upon the "difficulty" (target) set by the pool operator, the degree of "smoothing" that the pool operator applies to the displayed statistics, your hash contribution (a bigger contributor, will have a smaller coefficient of variation in their displayed hashrate, again for statistical reasons) etc.
Things are further complicated because many of the affected pools are "multi-coin" pools. The pool server automatically scans multiple cryptocoin networks, and various cryptocoin exchanges, to work out which coin is most profitable, the server will then jump between coins every few seconds or minutes as needed. For various technical reasons, different coins have different "stale" and "orphan" rates - "hits" which should have resulted in new coin creation, but where the hit was rejected (either immediately - stale) or initially accepted, then rolledback (orphan). Some of the alternative coins had rather dubious technical designs which could lead to massive reject rates, and this too could result in displayed hash rates fluctuating like mad.
The final issue is that many pools were often run by rank amateurs, and were targets for hackers/DDos like red-rags are to a bull. DDoSes, random server crashes, bandwidth exceeds, etc. were all common place, as well as various software bugs in "multi-pool" backend software would cause miners to end up disconnected from servers. Smarter miners would have typically have several pools configured on their mining hardware, so that the software could fail-over to another server. However, even that wasn't always successful. I once left my mining hardware unattended for a week, and configured it with 8 pools. When I checked the logs when I got back, there was a period of about 24 hours when the mines were idle, as all servers were off line.