If you don't watch the errors (or the alert fails in our case) for a few days then the subscription will be marked inactive.
Issues with the login account used will prevent a subscription from being active. It will simply fail to log on.
Also, if it has been inactive for a while then the subscriber will be out of sync - as in the case with updatable transactional subscriptions.
Finding the cause of the inactivity is best viewed from the Job history, not replication monitor (which says it is inactive, not why). Find the job, check the history out to identify the cause.
1. Stop the job. (or all replication jobs for the database (including from other publications eg 2 way upd...trans...repln))
2. Apply fix: Change the subscription properties to use a different account (if this was the cause).
3. Apply workaround: Use the preferred update script or sp mentioned before to set the status = 2 (applies to each articles in the publication) in MSsubscription
4. Restart the job. Watch the Job Activity as well to make sure it is running OK. If not, find the cause, repeat steps.
If you are still getting a failure caused by undistributed transactions failing to get through then you may have to clear the MSrepln_commands and manually sync changes using RedGate SQLCompare before restarting the job.
Simply reinitialising a subscription isn't always practical when the publication database is over 20Gb, the subscriber has a crap connection on the other side of the world and has only a small maintenance window to get the job done.