better still, allow a timeout period to be specified on each flow. By all means have an upper limit of, say, 365 days, and leave the default at 30 days if not specified.
I get round this by having a parent flow send a custom approval email, then a rest call to start a child flow. The child flow has a condition: if approval status equals 'pwending', delay until approval status is not equal to pending. A timeout is set on this as 720H (29 days). I have a rest call that calls the child flow after timeout.
Say you have a process which has 10 flows. Only the first one is started when, for example, a new item is added to a SharePoint list. At the end of the first flow, start the next flow with a rest call via HTTP. At the start of the 2nd flow, the trigger is HTTP when a rest call is received. IF your second flow is waiting until a date (or action), you put a timeout of 720H on it so it times out 29 days later if it has not met the date/action you were telling it to wait on. You then add an HTTP rest call to start the 2nd flow and configure it to do so based on the flow iself timing out (run after). The flow will just keep restarting every 29 days until the date/action is met.
The 3 above images are:
1. The HTTP call to start the 2nd flow.
2. The HTTP trigger to start the 2nd Flow.
3. The run after (failed/skipped/time out). This Flow adds a new SharePoint list item and then the team is sent an email. There are 17 flows involved in this process and I want to be able to sleep at night so this just lets us know instantly something is wrong. Just replace the email part with the HTTP from the first image.
You can now do this with the new Create Approval (v2) action. Read more here: https://flow.microsoft.com/en-us/blog/2019-release-wave-2-plan-and-may-updates-for-microsoft-flow/