The simple answer is nobody can prove that an algorithm won't break in a given period of time. The achievable goal is to increase the probability that no effective attack will be developed without warning. There are a couple of characteristics that indicate a particular cipher may remain secure and if degraded will do so 'gracefully'.
1. Time. Time is the major test of an algorithm's strength. The fact that researchers all around the world have had a decade to break SHA-2 and so far failed is a good sign. It doesn't mean that SHA-2 won't be broken tomorrow but the risk is significantly reduced compared to when SHA-2 was brand new. For that reason I have more confidence in the security of SHA-2 relative to SHA-3 over the short to medium term. Sometimes older is better.
2. Widespread usage. Time gives experts the opportunity to attack an algorithm but it doesn't mean much that nobody has broken xyz algorithm for a decade if nobody has tried to break xyz algorithm for a decade. A break on a major algorithm (SHA-2, AES, ECC) is a big deal and will attract more attention that some algorithm your brother cooked up. Correspondingly a large amount of the cryptanalysis occurs on the common high usage algorithms. This is one reason why rolling your own crypto is dangerous. The only way to have any confidence that it is secure is to have a large number of credible experts try to break it over a long period of time. That simply will not happen with an obscure algorithm.
3. Bit strength. 128 bit security (2^128 operations) is for all practical purposes beyond brute force both today and for the conceivable future. So why are there algorithms with higher bit strength if 128 bit is already 'unbreakable'? It is an insurance policy. Many attacks reduce the complexity of an attack. So instead of 2^128 operations to find a collision it might 'only' take 2^90 or 2^84. Those are larger numbers but it is feasible given enough time, money, and improved efficiency (Moore's law). On the other hand a break which reduces the complexity for a collision from 2^256 operations to even 2^160 is not usable. One should migrate away from the algorithm because there would be an increased risk that more sophisticated attacks would reduce that further but it would not present an 0-day risk. This is not an absolute guarantee. The break may be so severe that it cripples even a higher bit strength implementation but combined with the other principles that should be astonishingly unlikely.
4. An open transparent cryptographic algorithm/system It should go without saying that you should not trust your secrets to closed source systems which can't be independently verified, but this happens more often than you might imagine. Whole drive hard drive encryption for example is notorious for being a 'magical black box'. Optimally you would want to independently verify how the hash or cipher text is being produced. Cryptographic algorithms are deterministic, so if a device or software claims to be using AES-256 then given the same inputs (cleartext, key, IV) it should produce the same output as another known AES-256 implementation. If it doesn't then one of them is not implementing AES-256.
5. Nothing up my sleeves. Most cryptographic systems require some form of constants. It is always a risk that the constants chosen were chosen because they reduce the effectiveness of the system in a way known to the author but not others. 'Random' constants are a red flag because random values are unprovable. If an algorithm uses e971c59327cabde08439c813b70dae1a as a constant and the author says don't work it was generated on a CSPRNG you should be alarmed. How can you verify that e971c59327cabde08439c813b70dae1a was the result of a random roll and not deliberately chosen because it weakens the algorithm. Nothing up my sleeve numbers are usually used as a way to introduce pseudorandom constants. For example using the first 32 bits of the fractional part of the square root of the first n prime numbers. There is a low risk that such numbers could be chosen and also satisfy the conditions that would weaken the algorithm.
Combined these factors greatly reduce the possibility that an algorithm will break without warning however we can't prove that a cryptographic system is secure today or will remain secure tomorrow.
Provably secure hashing algorithms
There are 'provably secure' hashing algorithms. Most hashing algorithms use rounds of mix, rotate, and reduce functions and they are assumed there is no faster algorithm to 'break' them than brute force but the problem is that for all these algorithms there is no way to prove that no faster algorithm exists to find a collision. Provably secure hashing algorithms are based on mathematical proofs of known hard problems (like integer factorization). The 'provable' comes from the fact that it can be shown in a mathematical proof that a collision (or some other attack) will require a given number of operations in worst case scenario as long as no faster solution for the underlying mathematical problem is known. If that assumption turns out to be false so does the stated security but it does provide a stronger theoretical foundation as many of these mathematical problems are well understood.
The problem with provably secure hashing algorithms is they generally tend to take longer and require more resources for a given level of security when compared to traditional hashing algorithms. SWIFFT is an example of a provably secure hashing algorithm. It is not suitable for all circumstances so this isn't an endorsement of that algorithm for any particular usage. Given the lack of widespread usage it would violate at least one of the factors outlined above so I include it more for completeness.