Back to Blog
Server Administration•

FileMaker Server Monitoring Best Practices in 2026

Practical FileMaker Server monitoring best practices for logs, performance baselines, backups, schedules, SSL, and useful alerts in 2026.

FileMaker Server monitoring in 2026 should answer three questions quickly: Is the service available? Is it getting slower? Can we recover safely? A dashboard full of green status lights is not enough if backups are untested, scheduled scripts fail silently, or performance has degraded for weeks without a baseline.

The best monitoring plan combines current health, historical trends, useful logs, and recovery evidence. It should wake someone only when there is a clear next action.

Monitor the customer-facing path first

Start with the experience users actually depend on:

  • Can FileMaker Pro clients reach the host?
  • Are required databases open?
  • Is WebDirect responding, if you use it?
  • Are Data API or OData integrations succeeding?
  • Is the SSL certificate valid and far enough from expiration?

A process can be running while the service is unusable. Test the protocol and database path you care about, not only whether a server answers a ping.

FMDojo FMS Admin gives you a single place to review FileMaker Server status, connected clients, hosted files, schedules, logs, backups, SSL, Data API, OData, and WebDirect. Use that operational view to confirm the same path users report as broken before jumping to a restart.

Availability checks should be frequent and lightweight. Performance and log analysis can run less often. Separate them so a slow log download does not make the availability monitor look like an outage.

Build a FileMaker Server performance baseline

Claris exposes server statistics in Stats.log. Important signals include cache hit percentage, cache unsaved percentage, disk throughput, network throughput, remote calls, elapsed time per call, wait time per call, and I/O time per call.

One sample rarely proves anything. Record the normal range during:

  • A quiet period
  • A typical workday
  • A known busy period
  • Backups and scheduled imports
  • Month-end or other business peaks

Then alert on sustained deviation from that baseline. A short disk spike during a backup is expected. Rising elapsed time every afternoon may indicate a solution or capacity issue. High I/O time with a low cache hit percentage points in a different direction than high wait time with a healthy cache.

Do not turn Claris’s example numbers into universal thresholds. Database size, storage, user behavior, integrations, and calculation design all affect the baseline. Compare the server to itself first.

FMDojo’s live statistics view is useful when you need to connect a user complaint to current server evidence. Pair it with a Snapshot when you suspect a solution change—new unstored calculations, relationships, fields, or scripts—rather than assuming the host is undersized.

Know which FileMaker Server log answers the question

FileMaker Server separates operational evidence across several logs:

  • Event.log covers service events, files opening and closing, consistency checks, configuration errors, and scheduled-task events.
  • Stats.log records server performance and client counts.
  • ClientStats.log provides detailed client activity.
  • TopCallStats.log identifies expensive client requests.
  • FMSEScriptErrors.log records server-side script errors.
  • Access.log records client access activity.
  • fmdapi.log covers FileMaker Data API activity and errors.
  • fmodata.log covers OData API activity.
  • wpe0.log covers Web Publishing Engine and WebDirect activity.
  • fac.log covers Admin Console and Admin API activity.

Start with the symptom. For a slow layout, correlate TopCallStats.log, client statistics, and the time of the complaint. For a failed scheduled script, check the schedule state, Event.log, and FMSEScriptErrors.log. For a failing integration, use the matching Data API or OData log instead of searching every file.

Download or retain logs long enough to compare incidents, subject to your security and privacy requirements. Logs may contain filenames, account names, IP addresses, request paths, and other sensitive operational data. Restrict access and avoid copying raw logs into general chat or tickets.

In FMDojo FMS Admin, use the logs view to keep the server, time range, and symptom together. Ask FMDojo can help explain a selected error, but the log remains the evidence. Do not accept an AI explanation that contradicts the actual server state.

Monitor schedules by outcome

A schedule being enabled does not prove its last run completed correctly. Track:

  • Whether the schedule is enabled
  • Its next expected run
  • Its last start and finish
  • Its exit or error result
  • The business outcome it was supposed to produce

For a nightly import, the real outcome may be “today’s source file was processed and 1,248 records were reconciled,” not merely “the script started.” For a backup schedule, it is “a complete backup exists and can be restored,” not “the backup command ran.”

Claris notes that schedule activity is written to Event.log. Server-side script errors may also appear in FMSEScriptErrors.log. Build alerts around missed runs, nonzero errors, unusual duration, and missing output.

If a scheduled script can run concurrently with backup or file operations, test that pairing. FileMaker Server uses separate queues for some schedule and file commands, so two individually safe tasks can still compete for resources.

Treat backups as a restore capability

Monitor backup age, completion, storage capacity, and copy health. Then test restores on a schedule.

A good restore test verifies:

  1. The backup files are present and readable.
  2. The database passes consistency checks.
  3. The restored file opens in an isolated location.
  4. Expected accounts and integrations behave correctly.
  5. The team knows the recovery steps and decision owner.

Keep at least one backup outside the server’s primary storage failure domain. A backup on the same failing volume is not enough. Document retention and encryption requirements, and confirm old backups are removed according to policy rather than only when a disk fills.

FMDojo FMS Admin can show backup and disk evidence alongside server health. Use it to identify stale backups and capacity risk, then follow the approved recovery procedure. A monitoring tool should never turn a restore or restart into an unreviewed automatic response.

Alert on conditions people can act on

Useful alerts include:

  • The FileMaker service or required endpoint is unavailable
  • A required database closed unexpectedly
  • A scheduled task missed its expected window
  • Backup age exceeds policy
  • SSL expiration is approaching
  • Disk free space is below a defined runway
  • Error rates or latency remain above the normal baseline
  • Data API, OData, or WebDirect failures cross a sustained threshold

Every alert needs the server identity, time, observed value, expected value, evidence link, and first safe diagnostic step. Avoid messages such as “server unhealthy” with no cause or destination.

Use warning and critical levels. SSL expiration at 45 days is planning work; expiration at 3 days is urgent. A single slow call is evidence to retain; ten minutes of elevated call time may warrant an alert.

Review the monitoring system itself

Once a month, verify that monitors still run, recipients are current, log collection has not silently stopped, and alert links still work. After every incident, ask which signal detected it first and which signal should have.

The official Claris guides to monitoring FileMaker Server, server statistics, and schedules describe the underlying evidence. Your monitoring plan turns that evidence into an operational habit.

What is new in FM Dojo related to this

FMDojo FMS Admin brings server health, live statistics, logs, schedules, backups, SSL, Data API, OData, and WebDirect into one operational workspace. Use FMS Admin to inspect current server evidence, then use Snapshots when a performance change may come from the FileMaker solution itself.