How Files.com Logs Help You Troubleshoot Faster

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.

What Logs Can You Access

If your user account has log permissions, Files.com records every meaningful action on your site, and you can pull up any of these:

• Settings changes. Any update to your site configuration.
• Site history. A full record of site-wide activity.
• Automations. Whether each automated workflow ran, succeeded, or failed.
• File transfers. Every upload and download, including FTP, SFTP, and WebDAV sessions.
• Outbound connections. Activity on the remote servers your site syncs to or mounts.
• Email logs. Inbound and outbound email.
• Webhooks. Calls to and from your integrations.
• Logins. SAML and LDAP authentication attempts and directory-sync results.
• Public hosting. Activity on files you've published publicly.
• API logs. Every API call made on your site, across any interface.

Between them, these cover every action the platform takes, so nothing important happens without a record you can find.

Where to Find Logs in the Web Interface

There are two main places to look, depending on how narrow your question is.

File History

When you already know which file or folder is involved, start here.

• Open the File Manager tab.
• Open the folder's menu and click File History.

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.

Site-Wide Activity Logs

When you don't yet know where the problem is, look across the whole site.

• Open the Logging menu in the left sidebar.
• Click the History tab to see site-wide activity.

You can search this view by specific action or by folder path, which is how you find the one event that matters among thousands.

Using Logs to Solve Problems

Logs aren't only a paper trail — they're how you fix things fast. Two common cases show the pattern.

Resolving a File Permission Issue

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.

Diagnosing a File Transfer Failure

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.

Reading Logs from the Command Line

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.

Why Logging Matters

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.

Logging on a Modern File Platform

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.