Synonyms never become invalid. That is, their STATUS in the DBA_OBJECTS family of views is never INVALID. The immediate reason is that they are not recorded in the data dictionary (as seen through the DBA_DEPENDENCIES family of views) as being dependent on their referent. So if the referent becomes invalid or is dropped and its dependents are marked as invalid, then the status of the synonym remains unchanged.

That probably leaves you asking why synonyms are not regarded as being dependent on their referents. I guess that the answer is just that it is not done because it is not necessary. The purpose of dependency tracking and invalidation is to cause recompilation when the contingent object is next referenced. However, synonyms do not need to be recompiled because they have no metadata of their own, unlike views for example which have column metadata.

It is possible to get an ORA-00980: synonym translation is no longer valid error. This refers to an inability to create or navigate a synonym translation in the library cache. A synonym translation is distinct from the synonym itself (which remains valid). It is a library cache data structure representing a particular use of the synonym. It is effectively a pointer in the dependent library cache object from the library cache object for the synonym to the library cache object for the ultimately referenced database object (ultimately, because the immediate referent might be another synonym). You can see synonym translations in X$KGLTR. KGLHDADR is the address of the dependent object; KGLTRORG is the synonym object; and KGLTRFNL is the ultimate referent.

There are corresponding dependency records to represent the dependency of the dependent object on both the synonym and the ultimately referenced object (and in the case of public synonyms, a dependency on the non-existence of an object of that name in the current schema). The dependency records can be seen in X$KGLDP.

As an aside: It is interesting to note that if an object contains two or more distinct references to the same object, they each get their own dependency record. They are distinguished in X$KGLDP by KGLDPPOS which is the offset in bytes to the reference in the dependent object. This is necessary because the dependent object may require different access permissions to the referenced object for each reference. So one needs to be careful about apparent duplicates when joining to X$KGLDP.

What this all means is that when you are looking for invalid database objects to clean up, you should also look for synonyms without referents.

I was wondering, under what condition would a synonym become invalid.