A log is a record of something the app did. It might show when that staff account signed in, which files it downloaded and whether someone had changed its access. Those details can help the business work out what happened later.
But the app can record all eighty downloads without telling anyone. If nobody opens the log, the business learns nothing that night.
The UK's National Cyber Security Centre makes this distinction: logs help people investigate what happened; monitoring means actively checking for signs of a problem. It also says the amount of monitoring should suit the system and its risks. Some businesses may only need records they can examine if something goes wrong. Others need alerts that get someone's attention sooner.
Here, a sudden pile of downloads might be worth flagging. So might a new administrator account or repeated attempts to sign in. The alert doesn't prove an attack. Perhaps the customer asked for a copy of every file. Perhaps the business just hired a new administrator. Someone has to check.
What is worth recording?
An app can produce plenty of logs and still miss the thing the business cares about. A list of pages that failed to load helps when the site breaks. It won't explain who gave a former employee access to customer files.
OWASP's guidance on logging includes events such as failed sign-ins and changes to access. For a booking tool, the business may mainly need to know whether appointments are going through and who changed staff access. For a portal holding confidential files, downloads and permission changes matter too. You have to know what the app does before declaring its logging “basic.”
The records also need to be somewhere the people responsible can find them. If someone using a compromised account can delete them, they won't be much help during an investigation. And please don't put passwords, private keys or whole customer documents into a log. OWASP warns against logging secrets and sensitive information. It would be quite an achievement to investigate a possible leak by creating another one.
Who gets the alert?
Suppose the portal sends an email about those eighty downloads. Where does it go? To the business owner? To the developer maintaining the app? To an inbox created during setup that nobody has opened since?
The client and developer can decide that before launch. The person receiving the alert needs to know how to check whether the activity was expected and who can remove access if it wasn't. If the developer will help investigate, the business needs a way to reach them. If the business handles its own staff accounts, someone there needs to know how to disable one.
A small company doesn't automatically need a security team staring at screens all night just because it has an app. It does need to decide how quickly it wants to hear about a large download of confidential client plans. That answer may be different for a tool that sends appointment reminders.
Turning on every possible alert won't help if ordinary activity produces so many warnings that people stop reading them. OWASP calls this “alarm fog”. Pick events someone can investigate, and make sure the alerts reach that person.
What does the subscription tell you?
HighLevel does notify people about some events. Its system-email guide says the agency gets an email when a user is added. It also alerts a user when their phone number is changed. And agency admins can look through audit logs of user changes.
In my experience, hardly anyone checks these features when they sign up for a platform. Mention a custom app, though, and suddenly monitoring becomes a deal-breaker. Fine. Ask who gets the alerts for the software you already use, too.
Those are specific features. They do not establish that every unusual action in a customer's account will trigger an alert. I couldn't verify from HighLevel's documentation that it has a built-in warning for something like the eighty-file download above. It also offers real-time notices to connected software when users are added, changed or removed, which a developer could use to set up additional alerts.
So if a business relies on HighLevel, it is worth checking which events it already emails about, which records an admin can inspect and whether anything else needs setting up. The provider manages security of the platform; it cannot know every time a particular business expected someone to download its client files or change its staff access. A custom app needs answers to those questions too.
Ask me what an app I'm building records, what triggers an alert and who receives it. I should be able to answer. The comment section cannot do the audit for me.