From I know about the echo command as you are using it in your crontab, is that it will display that on the terminal since you did not specify anything else. Also, since the echo command is after the &&, it will only run if the previous command finishes with an exit code of 0.
Do you know how the app is exiting as that will determine if the echo command will run?

Since getting mail working just to see if the command is running may be a bit more effort, what about just echoing the line to a file in /var/log? That way you know it ran just by directing the output of echo to a file that you have log rotate deal with.

cron ran the job. You will not see an App1 done message because cron is not associated with a terminal. You could write the message to a file somewhere like
/usr/bin/echo "App1 done" >> /tmp/app1.log

if you did not get the desired results then you will need to look at App1. Without knowing anything specific make sure that paths are absolute. Does the App require any global parameters?

Does app1 have anything that says to mail root when it successfully completes?
As has already been noted the echo command would echo to a terminal but with cron it has no where to go.

You might consider changing the echo command to a mail to command. or put that crontab line into /etc/crontab instead of the personal crontab for root.

Definitely not...have used this method “forever”...soon learned that 5 minutes was to long, however I’m just not that patient.

That said, my system logs all cron runs in /var/log/cron

Unless the job is running under root's crontab, there will likely be permission problems creating breadcrumb files like that in /var/log. "/tmp" should work just as well during a debugging effort.

I'd spend some time figuring out why email isn't working. That's a prime tool (for me, anyway) to receive status reports, etc. without having to manually locate and inspect log files. Getting email working should be an essential first step when setting up the system. Local emails should be a snap to have working without a lot of fuss.

There's a LOT of ways to leave evidence behind that a cron job has run. If this is still a problem for the OP, I suggest using:
if the OP's system is configured to use traditional syslog logging or:
if systemd's logging is being used, to watch for log entries indicating that a cron job has been run.

Using the "logger" command in the script that's being run via cron can be helpful---you'll see the logger message in the system logs.
My experience with failing cron jobs is that some assumption about the environment is not valid and the script runs interactively but not when run under cron. Once email is working properly, even those failures ought to result in an email about the failure. Try:
which is handy in that it shows the environment that is defined for cron job---probably not what the user has set up when working at a terminal. Any script you run that needs more than what you get back in the output of the above cron job will have to include those missing items.

Aside: Running "crontab -e" is, IMHO, a bad way to manage one's cron jobs. You're one major problem requiring a re-install away from losing your cron job schedule. Keep it somewhere under $HOME and use a command like "crontab ~/my_master_crontab_file" to update the cron schedule when needed.

For a quick look I usually redirect output to a notification if fail

Thank you so much.
File created, but not with the date and time:
Why?

% are chron special characters and need to be escaped i.e. add a backslash \ before it.

Excuse me, I used below form:
How can I fix it?
To fix previous form, I must correct it as below?

That is correct.

I would change that last line to the below. The way you have it the output would be "App1 done:date +\%Y\%m\%d" while my change makes it "App1 done: 2021-02-03"
and it should work fine. If you want the full date with day, time, and day of week format the simple date command without the formatting as $(/usr/bin/date) will work as well and would give you "App1 done: Wed Feb 3 12:02:47 PM CST 2021"

Your earlier line would have worked except for the \ instead of / in the date command

You will also need to make certain the log file is able to be written to by the user running this cron job or the logging will still fail.

Note that your command only logs a success of the backup. If you also want to log failure then a slight change to the command will do that as well.
This way you get a log entry every time the job runs telling you the status instead of a missing entry when it fails

No!
I used below syntax:
And the output is:

If you read my post #26 above you would see the change I made that allows that to work correctly.

That is because you did not use the exact syntax of the provided cron job.

too late...

I used below syntax and got the same result too: