TL;DR
- Enterprise, Unlimited, and Performance editions (and Developer Edition) expose a set of daily
EventLogFilelogs, logins, API usage, Apex errors, and more, for free. You do not need the paid Event Monitoring add-on or Shield to read them. - The catch is retention: on the free tier those logs are kept for roughly one day, then they are gone. Miss a day and that day's evidence no longer exists.
- The fix is to capture them every day and store them yourself, which turns a one-day window into a rolling history you own.
- The sf-audit plugin ships
sf audit events pull, a read-only, idempotent command that downloads the free logs to local disk and is safe to run from cron or a scheduled GitHub Action. - This gives most orgs a real security baseline for zero licence cost, and a clear-eyed view of when Shield actually becomes worth buying.
What You'll Learn
- Which event logs Salesforce gives you for free, and on which editions
- Why the one-day retention window is the whole problem, and how to beat it
- How to capture the logs with one command and a daily schedule
- What to actually watch in the data once you have it
- When the free tier runs out of road and Shield earns its price
The Problem
Ask most admins how they would investigate a suspicious login or a data export after the fact, and the honest answer is that they cannot. They assume that seeing login and API history requires Salesforce Shield or the Event Monitoring add-on, which is a five-figure line item, so they never turn on any monitoring at all. Then an incident happens, someone asks "who exported that report, and when," and the answer is a shrug.
The assumption is wrong. Every Enterprise, Unlimited, and Performance org already generates a set of EventLogFile logs for free, covering logins, API calls, Apex exceptions, and page activity. The reason nobody uses them is not cost, it is retention. On the free tier those logs live for about a day before Salesforce deletes them. So the data exists, but by the time you go looking for it, it is gone. A monitoring capability that only remembers yesterday is not much of a capability.
Common questions this article answers:
- Can I get any Salesforce event monitoring without paying for Shield?
- Why does my EventLogFile data keep disappearing?
- How do I keep a history of logins and API usage that I can actually search?
Quick Answer
Salesforce exposes daily EventLogFile logs on Enterprise, Unlimited, Performance, and Developer editions without the Event Monitoring add-on. They cover logins, logouts, API usage, Apex exceptions, and URI or page activity, and the running user needs the "View Event Log Files" permission to read them. The one limitation that matters is retention: the free tier keeps them for roughly a day. So the whole game is to capture them daily and store them somewhere you control, which converts a one-day window into a permanent, searchable baseline. The sf-audit plugin does this in one command:
sf plugins install @cclabsnz/sf-audit
sf audit events pull --target-org myOrg
It is read-only, it stores the logs under ~/.sf/event-baseline/{orgId}/, and it skips anything already saved, so you schedule it once a day and let it build history. When the free tier's limits start to bite, that same baseline tells you exactly what Shield would add.
What you get for free
The base platform, on Enterprise, Unlimited, Performance, and Developer editions, generates EventLogFile records at a daily interval. Each record is a CSV of one event type for one day: a Login file, an ApiTotalUsage file, an ApexUnexpectedException file, a URI file for page activity, and others depending on your org. This is genuinely useful security data. Logins tell you who got in and from where. API usage tells you which integrations are doing what. Apex exceptions surface errors that never reached a user. You do not need Shield to generate any of it.
Two things gate access rather than cost. First, edition: the free daily logs are on Enterprise, Unlimited, and Performance, and Developer Edition exposes them too, which makes them easy to explore. Other editions need the Event Monitoring add-on. Second, permission: the user reading the logs needs "View Event Log Files," which is separate from ordinary admin access, so a fresh integration user will not see them until you grant it.
What the free tier does not include is the hourly, near-real-time event logs, the full set of event types, Event Monitoring Analytics, and Transaction Security enforcement. Those are the paid tier. But for a baseline of who logged in, what the APIs did, and what broke, the free daily logs are plenty.
The retention trap, and how to beat it
Here is the entire problem in one sentence: on the free tier, EventLogFile records are retained for about a day. Generate a Login log today, and tomorrow it is gone. The paid Event Monitoring tier extends retention (up to around a year), which is a large part of what you are buying. On the free tier, retention is your responsibility.
Beating it is conceptually simple. Every day, before the window closes, query the available EventLogFile records, download each one's CSV body, and save it somewhere durable. Do that daily and you accumulate a history that outlives Salesforce's one-day window: last week's logins, last month's API spikes, the exception that started three Tuesdays ago. The data was always being generated; you are just keeping it.
The mechanics are a read-only query for the day's EventLogFile records, then a GET of each record's LogFile field, which returns the CSV. It is entirely doable by hand or with a small script. The awkward parts are doing it reliably every day, not re-downloading what you already have, and handling the org that has the add-on (hourly logs) differently from the one that does not. That is the bit worth automating.
Capturing it with sf audit events pull
The sf-audit plugin ships a command that does exactly this capture, built to be run on a schedule.
sf plugins install @cclabsnz/sf-audit
# Pull today's free EventLogFile logs to local disk
sf audit events pull --target-org myOrg
It queries the daily EventLogFile records for the window, downloads each CSV, and saves it to a predictable path:
~/.sf/event-baseline/{orgId}/{EventType}/{LogDate}-{Id}.csv
plus a per-run manifest recording what it pulled. Three properties make it safe to schedule. It is strictly read-only, using GET requests only, so it never changes anything in the org. It is idempotent: any log already on disk is skipped, so running it twice in a day, or having two runs overlap, costs nothing and creates no duplicates. And it fails gracefully: if the org lacks the "View Event Log Files" permission or the edition does not expose free logs, it exits with a plain explanation instead of an error.
Run it once a day and you have your baseline. From cron:
# 7:15am daily, log the output so you can see it ran
15 7 * * * sf audit events pull --target-org myOrg >> ~/.sf/event-baseline/pull.log 2>&1
or as a scheduled GitHub Action if you would rather the capture run in CI than on someone's laptop. A few flags cover the common needs:
# Widen the window (for example after a missed day)
sf audit events pull --target-org myOrg --since 3
# Only pull the log types you care about
sf audit events pull --target-org myOrg --types Login,ApiTotalUsage
# Store under a project directory instead of ~/.sf
sf audit events pull --target-org myOrg --output ./event-baseline
The --since window is a safety net rather than a substitute for running daily: on the free tier, anything older than the retention window is already gone, so a missed week cannot be recovered by asking for it later. The point of the daily run is to catch each day before it expires.
What to actually watch
Capturing the logs is half the job; the value is in reading them. A few things are worth looking at first, because they are where real incidents show up.
Logins are the highest-signal file. Watch for successful logins from unfamiliar countries or IP ranges, a single user authenticating from many distinct IPs in a short window (a credential-sharing or compromise signature), and bursts of failures followed by a success. API usage tells you which integrations are active and whether one suddenly started pulling far more than usual, which is both a cost signal and an exfiltration signal. Apex exceptions surface errors that never reached a user, including failures in scheduled jobs that would otherwise fail silently. And if your org exposes report-export activity in the free logs, large or unusual exports are exactly the event a data-loss investigation turns on.
You do not need a SIEM to start. Grepping a month of Login CSVs for a specific user, or loading them into a spreadsheet to chart API volume, already puts you ahead of an org that kept nothing. When the volume outgrows that, the baseline you have been collecting is precisely what you would feed into Splunk or Sentinel.
When the free tier runs out of road
Being honest about the limits is the point, because it tells you when to spend money and when not to. The free daily logs are enough when you want an after-the-fact record of logins, API usage, and errors, and you are content to review them yourself. That covers a lot of orgs.
Shield and the Event Monitoring add-on earn their price when you need what the free tier structurally cannot give you: retention measured in months rather than a day without you having to capture it, the hourly near-real-time logs for faster detection, the full set of event types, Event Monitoring Analytics dashboards, and Transaction Security Policies that block risky actions as they happen rather than recording them after. If you are in a regulated environment that requires a year of tamper-resistant audit history, or you need to stop a bulk export in real time rather than read about it tomorrow, that is a Shield conversation.
The sensible path for most orgs is to stand up the free baseline first, run it for a few weeks, and let the data show you whether the gaps that remain are worth paying to close. You will make that call from evidence rather than from a sales deck. To see where your broader posture stands alongside this, including whether Event Monitoring and Transaction Security are configured at all, the same plugin's full audit is covered in Catch Salesforce Security Gaps in One Command.
Frequently Asked Questions
Do I really get any event monitoring without buying Shield?
Yes. Enterprise, Unlimited, and Performance editions, plus Developer Edition, generate daily EventLogFile logs covering logins, API usage, Apex exceptions, and page activity, with no Event Monitoring add-on required. The only real limit is that the free tier keeps them for about a day, which is why you capture them daily rather than relying on Salesforce to hold them.
Which editions and permissions do I need?
The free daily logs are available on Enterprise, Unlimited, Performance, and Developer editions; other editions need the Event Monitoring add-on. The user reading the logs needs the "View Event Log Files" permission, which is separate from general admin rights, so grant it to whichever user or integration runs the capture.
Is capturing the logs safe to run against production?
Yes. The capture is strictly read-only: it queries EventLogFile and downloads each log's CSV with GET requests only, and writes nothing back to the org. sf audit events pull is also idempotent, so scheduling it daily, or running it twice, never causes duplicates or side effects.
How is this different from just buying Event Monitoring?
The free tier gives you the same daily log data, but with one-day retention and without the hourly logs, the full event-type set, Analytics, or Transaction Security enforcement. Buying Event Monitoring or Shield mainly buys you long retention without self-capture, near-real-time hourly logs, and the ability to block actions rather than just record them. Starting free lets you decide whether those additions are worth it based on your own data.
What happens if I miss a day?
On the free tier, logs older than the roughly one-day retention window are deleted, so a missed day generally cannot be recovered by widening --since later. That is the whole reason to run the capture on a daily schedule: each run preserves that day before it expires.
Key Takeaways
- Free event monitoring exists. Enterprise, Unlimited, Performance, and Developer editions expose daily
EventLogFilelogs with no Shield or add-on. - Retention is the only real catch. The free tier keeps logs for about a day, so you must capture them daily or lose them.
- Automate the capture.
sf audit events pullis read-only and idempotent, built to run from cron or a scheduled Action and store a rolling baseline under~/.sf/event-baseline/. - Read the logins first. Unfamiliar IPs, one user from many IPs, and failure-then-success bursts are the highest-signal patterns.
- Buy Shield from evidence. Stand up the free baseline, then let the gaps that remain justify the add-on, rather than the other way round.
What's Next?
Recommended Reading:
- Catch Salesforce Security Gaps in One Command
- Salesforce Guest User Exposure: How sf-audit Grades It by Real Reachability
- sf-audit: 61 Checks, Attack Chains, and Compliance Mapping
- Salesforce Security Enforcement in 2026: Every Change, Date, and What Admins Must Do
Action Items:
- Confirm your edition exposes free daily logs and grant the running user the "View Event Log Files" permission.
- Install sf-audit and run
sf audit events pull --target-org <alias>once by hand to see what your org exposes. - Schedule the pull daily from cron or a GitHub Action, then review a week of
Loginlogs to set your normal.