Robert Abela, founder and CEO of Melapress, delivered a focused and practical talk on why most agencies are operating with dangerously incomplete visibility into what is actually happening on their clients' WordPress websites. Despite the widespread use of activity log plugins and monitoring tools, Abela argued that having more tools does not automatically translate into real visibility. The core problem is that agencies typically deal in fragments rather than complete pictures: logs that exist but are too vague to act on, logs that disappear when they are needed most, and a fundamentally reactive posture that forces agencies to respond to client complaints rather than getting ahead of problems.
Abela structured his talk around four distinct visibility failures — incomplete visibility, no visibility, delayed visibility, and deletable visibility — and proposed a framework of four requirements that genuine visibility must satisfy: detail, availability, reliability and trustworthiness, and centralisation. He used live comparisons of different WordPress activity log plugins to show concretely why specificity matters, and explained how configurable real-time alerting can shift agencies from reactive firefighting to proactive
management. The session concluded with a Q&A covering website hardening, two- factor authentication, password management, and the performance implications of running activity logging plugins at scale.
The central message: visibility is not a feature you bolt on. It is an operational capability that should guide how an agency is run.
Key takeaways
- 01More tools does not equal more visibility. Agencies frequently have multiple monitoring tools running and still lack a complete, coherent picture of what is happening on client sites.
- 02Generic logs are not enough. A log entry that says "product updated" or "profile updated"
- 03is nearly useless in a real incident. You need to know exactly what changed, what the previous value was, and what it changed to.
- 04The client calling first is already a failure. If a client contacts you about a problem before your monitoring catches it, there is already friction and a trust deficit in play, regardless of how quickly you resolve the issue afterward.
- 05Logs stored on the website are vulnerable. When a site crashes or is hacked, logs stored locally may become inaccessible or may be deliberately deleted. Off-site or third-party log storage is a critical safeguard.
- 06Attackers routinely delete logs. Clearing activity logs after a successful hack is standard practice. If you have no off-site copy, you may have no record of how a breach occurred.
- 07Real-time, configurable alerts are what separate proactive agencies from reactive ones. The ability to define specific trigger conditions — role, time of day, IP address range, event type — allows agencies to be notified before a situation escalates.
- 08Every client's website is different. Alert configurations should be tailored to how each client actually uses their site, including their team structure, working hours, and geographic spread.
- 09Centralised log management across all client sites enables trend detection. When logs from multiple sites feed into one place, it becomes possible to spot patterns and systemic issues that would be invisible when looking at sites individually.
- 10Activity logging should be set up before something goes wrong. Installing a logging plugin after an incident to investigate it is too late. Logs only capture events from the moment they are activated.
- 11Visibility is how you justify your agency's value. Proactively identifying, fixing, and reporting on issues — before the client notices — is a direct demonstration of the managed service value agencies sell.
The Reality Check: What Happens When Something Goes Wrong
Abela opened with a simple but pointed scenario: something happens on a client's website. It could be a crash, a failed order, an unexpected user change, or any number of incidents. The client calls you. Can you answer their question, or do you have to guess?
This framing was deliberate. The fact that the client calls first — before the agency has identified or resolved the issue — is itself a problem. By the time the phone rings, the client is already upset, already experiencing the consequences, and already forming a judgement about whether their agency is on top of things. The agency is immediately on the back foot.
Abela's diagnosis is that the root cause is not a lack of tools. Most agencies are using logs, using monitoring tools, using something. The problem is that they have fragments rather than complete visibility. They have pieces of the picture but not the whole picture. And when a site crashes, those fragments may not even be accessible.
He framed the downstream consequences clearly: slow answers lead to a lack of trust. A lack of trust leads to lost clients. In a business built on long-term managed service relationships, this is existential.
The Four Problems with Agency Visibility
Abela organised his diagnosis into four distinct types of visibility failure.
Problem 1: Incomplete Visibility The most common form of visibility failure is not the absence of logs, but the inadequacy of what those logs actually capture. Many agencies are running activity log solutions, but the information those logs provide is too vague to be actionable.
A typical example: the log records "product updated." This tells you almost nothing. What changed about the product? Was it the price? The stock level? A shipping class? A product image? These distinctions matter enormously. A price change from 200 euros to 20 euros is a crisis. A change to a product description is routine. Without knowing what specifically changed, and what the previous value was, the log entry provides no meaningful basis for action or investigation.
The same applies to user-related events. A log that says "profile updated" is nearly useless.
Was it the user's first name? Their email address? Their password? Their user role? The difference between a first name update and a password or role change is enormous in terms of security implications and urgency.
Problem 2: No Visibility The second failure mode is more severe: logs that simply become inaccessible at the moment they are most needed. This happens primarily when a website crashes. If logs are stored in the website's own database or on the same server, a site that is down takes its logs down with it.
The consequence is a painful sequence of events: the site goes down, the agency must first scramble to restore the site to functionality, and only once the site is back up can anyone begin to look at the logs to understand what caused the crash. This adds time, adds stress, and dramatically extends the window in which the client is left without answers.
Problem 3: Delayed Visibility The third problem is the reactive posture that delayed visibility creates. No agency is going to monitor logs manually across 10, 20, or 50 client websites around the clock. It is not scalable, and in practice it does not happen. What this means is that when something goes wrong, the agency finds out when the client calls, not before.
Manual monitoring does not scale. This was stated as a straightforward operational reality rather than a criticism. The question is what you put in place to compensate. Without real-time alerting that is configured to flag the right events, agencies are structurally condemned to be reactive. They are waiting for the call rather than making it.
Problem 4: Deletable Visibility The fourth and perhaps most insidious problem is that logs can be deliberately or accidentally destroyed. Abela pointed to three scenarios: First, attackers who compromise a website routinely delete the logs as part of their exit process. Eliminating traceability is standard practice. If the logs are only stored on the compromised site, they are gone.
Second, logs can be lost through accidents: a client inadvertently deletes them, a plugin update overwrites something, a corrupted setting causes them to stop being written or to be cleared. These are not edge cases.
Third, logs are, in Abela's framing, a bit like backups: when you need them most, they disappear. The parallel is instructive. Most people understand that you need off-site, independently accessible backups precisely because local copies are vulnerable. The same logic applies to logs.
What Real Visibility Actually Requires
Having defined the four problems, Abela laid out the four qualities that genuine operational visibility must have.
1. Detail Logs need to capture not just that something changed, but exactly what changed, what the previous value was, who made the change, when, and from which IP address. The granularity of the log determines whether it is actionable in a real incident.
Abela illustrated this with a concrete case study. A WooCommerce store was shipping products to customers, and customers were repeatedly complaining that they were not receiving them. The issue, once a detailed logging plugin was installed, turned out to be that customers were placing an order, the store shipped, and then the customer immediately changed their shipping address in their profile. They were exploiting this gap to receive multiple products for free. A generic log that recorded "profile updated" would never have surfaced this pattern. Only a log that recorded the specific field that changed and what the old and new values were made the fraud visible.
He then demonstrated this point using side-by-side comparisons of multiple WordPress activity log plugins. When a user role was changed to administrator, most plugins recorded something generic. WP Activity Log recorded the specific change, the previous role, the new role, the username, the time, and the IP address.
When a plugin like Yoast SEO was installed, activated, and then had a specific feature disabled, most plugins recorded "plugin installed" and "plugin activated" and nothing more.
WP Activity Log recorded the specific setting that was changed and what it was changed to.
The WooCommerce example was particularly instructive: when a product price was changed from 200.01 euros to 200 euros and a stock quantity was reduced from 24 to 23, other plugins reported "product updated." WP Activity Log reported the exact fields that changed, the old values, and the new values.
Abela's point was not simply to promote his own product but to establish that the standard of detail that most agencies are working with is fundamentally inadequate for serious incident response.
2. Availability Logs need to be accessible regardless of the state of the website. If a site is down, the logs should still be readable. This requires logs to be stored or mirrored somewhere other than the local site database.
Abela framed availability in terms of proactive response: if you have the right monitoring in place, you can know about an issue before the client does, fix it, and then go to the client proactively to explain what happened and what was done about it. He described this as a vote of confidence toward the agency because it demonstrates that the agency is not reactive but on top of the game, actively justifying the managed service fee.
The contrast he drew was stark: being called by a frustrated client versus calling the client with a resolution already in hand.
3. Reliability and Trustworthiness Reliability means that logs are always accessible, including when the site is down.
Trustworthiness means that the copy of the logs you are working from has not been tampered with.
By default, activity logging plugins store logs in the website's database. Abela described this as acceptable for performance reasons but insufficient as a sole storage location. He recommended also writing logs to a log file outside the web-accessible directory, or to a dedicated log server such as AWS CloudWatch, or to a SIEM (Security Information and Event Manager) solution.
SIEM systems are third-party platforms designed to aggregate logs from multiple devices, systems, and sources and allow them to be analysed together. Abela explained that the advantage of sending a copy of logs to such a system is twofold: the logs cannot be tampered with or deleted from the website itself because the copy exists independently, and the logs are accessible even when the website is completely offline.
4. Centralisation When logs from all client sites feed into a single location, it becomes possible to see patterns and trends across the portfolio rather than only within individual sites. An issue that affects one site might be a coincidence; the same issue appearing across three or four sites simultaneously is a signal of something systemic. Centralised visibility allows agencies to catch these patterns early.
Trustworthiness means that the copy of the logs you are working from has not been tampered with.
Real-Time Alerting: Getting Ahead of the Client
A significant portion of the talk addressed how agencies can move from a reactive to a proactive model through configurable real-time alerts. Abela made clear that the goal is not to be watching logs manually — that is not feasible at any scale — but to configure the system to surface specific events that warrant immediate attention.
WP Activity Log supports alert delivery via email, SMS, and Slack. The alert conditions are configured through a flexible trigger builder that allows very specific conditions to be defined. Abela walked through an example: alert if a user with the role of shop manager logs in (event ID 1000) before 8 a.m. from an IP address that does not match the expected office IP range. This kind of specificity catches genuinely anomalous behaviour while minimising noise from routine activity.
Abela was careful to emphasise that what constitutes anomalous behaviour is different for every client. He compared two hypothetical e-commerce businesses, each with a team of ten. One team works from a single office: logins will cluster around normal business hours and come from a small set of IP addresses. The other team is fully remote and spread across time zones: logins will come at all hours from many different IP addresses. A login at 2 a.m.
might be completely normal for the remote team and deeply suspicious for the office team.
This means that effective alert configuration requires understanding how each client actually uses their website: their team structure, their working hours, their geographic spread, their workflows. Alert configuration is not a set-and-forget exercise applied uniformly across all clients. It is a bespoke process for each engagement.
Off-Site Storage and SIEM Integration
Abela devoted specific attention to the options for getting logs off the website itself. The default behaviour of all activity logging plugins is to store logs in the local WordPress database. This is fine for speed and performance, but it creates the availability and tamperability risks described earlier.
WP Activity Log provides several options. Logs can be stored in the main database, with older logs archived to a separate database table. Logs can be copied to a log file outside the web-accessible directory. Logs can be sent to a third-party log server such as AWS CloudWatch. And for organisations using SIEM solutions, WP Activity Log supports the syslog protocol, which is the standard method for forwarding log data to SIEM systems.
The practical effect of sending logs to a SIEM or other external system is that the logs exist independently of the website. If the website is hacked and the on-site logs are deleted, the external copy is untouched. If the website goes offline, the logs remain accessible. This is the off-site backup principle applied to activity logs.
Visibility as Proof of Value
Abela closed his main presentation with a point about the commercial and relational value of visibility. For agencies operating on managed service retainers, the challenge is always demonstrating value. A monthly report that says "we kept your website running" is weak evidence. Detailed logs that show exactly what was monitored, what was caught, what was fixed, and when are strong evidence.
More powerfully, being the one to proactively notify a client about an issue — with a resolution already in place — transforms the agency's position in the client relationship.
Instead of being the person who failed to notice something until the client called, the agency becomes the partner who was watching out for the client and resolved something before the client even knew there was a problem. This is the managed service value proposition made tangible.
Abela's summary was direct: visibility is not a feature. It is how you run your agency. If you are not one step ahead of your clients, you are not managing their websites. You are reacting to them.
If you are not one step ahead of your clients, you are not managing their websites.
Q&A: Hardening Advice for Agencies New to Security
Andrew Palmer invited questions, and one asked for practical advice for an agency approaching website hardening for the first time.
Abela gave a structured answer. He noted that recent reports from security vendors including Patchstack consistently identify two categories as the most common root causes of WordPress compromises: outdated software and user account problems.
For outdated software, he pointed to patch management tools and security vendors like Patchstack as the appropriate solutions.
For user account problems, he outlined several practical measures: Two-Factor Authentication: Abela recommended 2FA for anyone with elevated access such as editors and administrators. He acknowledged that the choice of 2FA method matters for the user experience. For WooCommerce stores with many customers, a 2FA app may be too much friction; automatic email-based 2FA may be more appropriate. Passkeys are a viable option but still difficult for average users to set up and manage reliably. Melapress supports 2FA through its WP 2FA plugin, including passkey support.
Password Management: Abela made a distinction between enforcing strong password policies and actually helping users comply with them. Enforced complexity requirements often result in users writing passwords on sticky notes or finding other workarounds. His
recommendation was to pair strong password requirements with active encouragement to use a password manager. Password managers allow users to have long, unique passwords for every site without needing to memorise or manage them directly.
Login Restrictions: Through Melapress's login security plugin, agencies can limit login attempts, lock out accounts after failed attempts, and restrict login windows by user role.
For example, administrators can log in at any time, while customers can only log in on weekdays during business hours. Editors might be restricted to specific days of the week.
These small constraints significantly reduce the attack surface.
Untrusted Device Detection: WP Activity Log can identify the device from which a user typically logs in (using cookies and related signals) and alert the user if a login occurs from an unfamiliar device. This provides an additional layer of protection against compromised credentials by catching the use of legitimate credentials from an unexpected device.
Abela's framing throughout this section was that users are not the problem per se — particularly non-technical users who are not security professionals — but that agencies have a responsibility to put systems in place that protect users despite their lack of security awareness.
Q&A: Performance Implications of Activity Logging Plugins
David Johnson raised a question about the historically poor performance impact of website change monitoring plugins. Abela acknowledged this directly, including some early-days issues with WP Activity Log itself.
He described the work that has been done to address performance: collaboration with WordPress core contributors including Mark Jacobs, and ongoing work with engineers from multiple web hosting providers. He outlined several configuration options that affect performance: storing all logs in the main database, archiving older logs to a separate table, copying logs to a third-party service and keeping only recent logs locally, or migrating all logs off-site entirely.
The fewer logs retained locally, the smaller the local database, which improves query performance and indexing. But beyond configuration options, Abela pointed to ongoing code optimisation as a continuous practice rather than a one-time effort.
His most concrete data point: one of their largest customers runs a WordPress multisite installation of around 3,000 to 4,000 sites with more than 15,000 users, and experiences no performance issues from the plugin. He acknowledged that edge cases and individual problems do arise but characterised the general performance position as solid.
Closing Remarks and Practical Recommendation
Andrew Palmer asked Abela for his single biggest takeaway for agencies. Abela's answer centred on accountability: not as a surveillance mechanism or a "big brother" approach, but
as something that works in both directions. Accountability protects the client, and it also protects the agency. When logs exist, agencies can prove what they did, when they did it, and that they were doing their job.
His practical call to action was unambiguous: get started. The most common mistake he sees is agencies waiting until after something goes wrong to install a logging plugin. At that point it is too late — activity log plugins only capture events from the moment they are activated.
There is no retroactive log to query.
Even the free version of WP Activity Log begins capturing logs for WordPress core activity immediately on activation, with no restrictions on core coverage. The premium version adds additional features including coverage for third-party plugins. His recommendation was to start with the free version and at least have something in place before an incident occurs.
The analogy he offered was insurance: nobody expects to need it until they do, and at that point it is too late to acquire it.
Plugin Features Referenced
Abela referenced several specific features of WP Activity Log throughout the session: Granular logging of exact field-level changes for WordPress core, WooCommerce, Yoast SEO, RankMath, WP Forms, and other supported third-party plugins Custom sensor development for unsupported plugins (relevant given the 60,000-plus plugins on WordPress.org) Configurable notification triggers with conditions based on user role, event type, time of day, IP address, and other parameters Alert delivery via email, SMS, and Slack Database archiving to keep the main database lean Off-site log storage via log files outside the web-accessible directory Integration with external log servers such as AWS CloudWatch Syslog protocol support for SIEM integration Multi-site and centralised log management for agency-wide visibility Melapress also makes WP 2FA (two-factor authentication) and a login security plugin offering role-based login time restrictions and untrusted device detection.
A 20% discount for Web Agency Summit attendees was available via a QR code displayed at the end of the session.
About the speaker
Robert Abela
Founder and CEO, Melapress
Robert Abela is founder and CEO of Melapress, a company building security and activity-logging tools for WordPress. He works with agencies on the monitoring and visibility practices that keep client sites, and client relationships, healthy.