The most common Files.com support question is some version of "why didn't this file arrive." The answer is almost always in the logs. A log is just a timestamped record of something that happened: somebody's session failed authentication, an automation ran but didn't match its trigger, a permission changed an hour before the partner tried to upload, a remote server rejected the destination path. Each of those events leaves a line you can read back later. The triage flow is the same every time: open the right log, filter to the time window, and follow the chain to the cause.
When you collect those records and keep them so they can't be quietly altered, you have an audit log — the running history an auditor (or you, at 2 a.m.) reads to prove who did what, when, and from where. This post is a walkthrough of the logs Files.com keeps and how each one fits into a real troubleshooting session.
If your user account has log permissions, Files.com records every meaningful action on your site, and you can pull up any of these:
Between them, these cover every action the platform takes, so nothing important happens without a record you can find.
There are two main places to look, depending on how narrow your question is.
When you already know which file or folder is involved, start here.
This shows every action inside that folder: the date and time, the user responsible, a summary of what happened, and the interface they used (web, API, or CLI). You can filter the view by start and end date, user, IP address, and interface to get straight to the entry you care about.
When you don't yet know where the problem is, look across the whole site.
You can search this view by specific action or by folder path, which is how you find the one event that matters among thousands.
Logs aren't only a paper trail — they're how you fix things fast. Two common cases show the pattern.
When files, folders, or users fail to update or sync, the cause is usually a permission that's missing or was revoked. Use the site history logs to find the failed action, the file path, and the user it happened to. Then open the User Accounts tab and grant the right permission. The log tells you exactly what to change, so you're not guessing.
Say a partner emails you five image files but only three show up in the File Manager. Start with File History to confirm which files actually landed. Then open the Inbound Emails Log under the Logging menu.
If the platform rejected the other two, you'll see a plain reason — for example, "File type not allowed on this server." From there, open Folder Settings in the File Manager and add the file extensions you want to accept. The whole answer came from two log views, with no back-and-forth with the partner.
If you'd rather work in a terminal than a browser, the Files.com CLI reads the same logs with a single command. It can print them as a table for a quick scan, or export them as a CSV file for a deeper review or a report. That makes it easy to fold log checks into scripts, automated workflows, and your own diagnostics instead of clicking through the web interface every time.
Good logs do four jobs at once. They let you diagnose an issue by finding its root cause quickly. They give you an audit trail that shows who did what across your site.
They surface inefficiencies in automations and transfers so you can tune them. And they help you work with outside partners by settling exactly what happened to a delivery. The difference between an audit you pass and an audit you scramble through is usually whether the record was already there to read.
Files.com is the cloud-native File Orchestration Platform: one platform that replaces the stack of legacy tools IT teams run to move files — SFTP and FTP servers, MFT suites, file-sharing apps, and the scripts holding them together. Because every transfer, login, automation, and API call runs through that one platform, every one of them lands in the same searchable history automatically. There's no separate logging server to stand up and no agent to bolt onto each box; the record is a built-in property of the platform, not an add-on.
That history is also tamper-evident and built to satisfy a real auditor, which is why teams under SOC 2 Type II or HIPAA lean on it. When you need to push those events into the tooling your security team already watches, Files.com streams them to your SIEM — the system that collects security logs from across your company. And if you're weighing how much visibility your file platform actually owes you, the difference between an audit trail and a raw log is worth reading before you commit.
See how the audit log works across the whole platform, or start a free trial — no credit card, live in minutes.
Google Cloud Storage is built for scalable object storage, not for file transfer workflows. Here are five common workflows GCS can't run on its own, and how teams add automation, orchestration, and secure transfer on top of it.
Financial institutions routinely move ACH files and transaction data between customers, core banking systems, and third-party processors. Learn how modern banking file transfer workflows operate and what IT teams should look for when managing secure, automated integrations across vendors.
As medical groups grow, file sharing turns into a compliance and operational problem. Here is how healthcare IT teams set up secure SFTP access, controlled upload pages, and automated transfers without a big infrastructure project.
4,000+ organizations trust Files.com for mission-critical file operations. Start your free trial now and build your first flow in 60 seconds.
No credit card required • 7-day free trial • Setup in minutes