[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f-rFGAWk6OWmzo2LB2NoLhci9_7HH8UbSPtdC4ubEAsg":3},{"item":4},{"id":5,"idKnowledge":6,"idDomain":7,"idCluster":8,"kindOverride":9,"slug":10,"title":11,"description":12,"bodyMarkdown":13,"bodyHtml":14,"author":15,"date":16,"createdAt":17,"topics":18,"image":26,"hasDownload":27,"fileName":28,"youtubeId":29,"domainCrumb":30,"clusterCrumb":33},"382","C65C5970-5B58-4746-8EDB-B4D07AB142B2","E46BDB0A-2979-1E40-93F7-AC40185848A5","B11BED08-2F4E-4C45-9373-6175FA721411","article","how-to-diagnose-filemaker-server-performance-problems","How to diagnose FileMaker Server performance problems","A practical, step-by-step guide to finding the real cause of a slow FileMaker system before you start changing code, hardware, or hosting.","Your FileMaker system used to feel instant. Now a layout that opened in half a second takes three or four, a nightly import that used to finish before anyone arrived at the office is still running at 9am, and your team has started joking about \"the system being slow again\" instead of reporting it as a real problem. Everyone has a theory — the server, the internet, \"that new script,\" too many users — but nobody has actually measured anything.\n\nThis article walks through how to actually diagnose a slow FileMaker system, step by step, before you spend money on a bigger server or a rewrite you may not need.\n\n## Why does \"it feels slow\" almost never point to the real cause?\n\n\"Slow\" is a symptom, not a diagnosis. A layout that takes 4 seconds to load could be caused by:\n\n- A poorly indexed field being searched on every record load\n- A script running unstored calculations across 40,000 related records\n- A remote user in another country connecting over a VPN with high latency\n- A container field storing full-resolution PDFs directly in the database\n- Another script, kicked off by someone else, hammering the same table at the same moment\n- FileMaker Server itself running low on RAM or CPU because a backup and a scheduled script overlap\n\nEach of these needs a completely different fix. Guessing wastes time and, worse, sometimes makes things worse — for example, adding indexes randomly can bloat the file and slow down writes without ever touching the actual bottleneck.\n\n## Where should you start looking first: client, network, or server?\n\nBefore touching any code, isolate where the delay actually happens. A simple, reliable first test:\n\n1. Have the affected user reproduce the slow action.\n2. Have someone in the same office, on the same network, try the identical action at the same moment.\n3. Have someone connecting remotely (VPN or over the internet) try it too.\n\nIf only the remote user is slow, you're likely looking at network latency or bandwidth, not a server or schema problem — a very common situation with teams that grew from one office to multiple locations or added home-working staff without revisiting their connection setup.\n\nIf everyone is slow at the same time, the problem is on the server or in the file itself.\n\nIf it's slow for one specific user only, check that user's machine: available RAM, disk space, whether antivirus software is scanning FileMaker's cache folder, or whether they're running an outdated FileMaker Pro client version against a newer server.\n\n\n\n## What should you check first on FileMaker Server itself?\n\nFileMaker Server ships with built-in diagnostic tools that are underused. Start here before installing anything new:\n\n1. **The Statistics tab in the Admin Console** — shows elapsed time, I\u002FO, and cache hit percentages per database. A cache hit ratio consistently below roughly 90-95% is a strong signal the server doesn't have enough RAM allocated for the size of your file.\n2. **Server-side statistics logging** — enable it and let it run for a day. It logs per-database read\u002Fwrite counts, network I\u002FO, and elapsed time in intervals you choose, so you can correlate a slowdown with a specific time of day (e.g. every day at 2pm, right when the scheduled import runs).\n3. **The Clients tab** — shows exactly who is connected and what they're doing right now. If one user's session is stuck in a long-running script, you'll see it here immediately.\n4. **Progressive backups and scheduled scripts overlapping** — a very common, completely invisible cause of slowdowns. If your nightly backup, a scheduled server-side script, and a scheduled import all fire within the same 10-minute window, every user connected during that window feels it, and nobody thinks to check the schedule.\n\n## How do you find the specific script or layout causing the slowdown?\n\nOnce you know the problem is server-side or file-side, narrow it down further:\n\n- **Enable the Data Viewer's script debugger with timestamps**, or better, wrap suspect scripts with `Get ( CurrentTimeUTCMilliseconds )` logging at key steps and write the results to a log table. This turns \"the import feels slow\" into \"step 14, the unstored calculation on the LineItems table, takes 8 of the 11 seconds.\"\n- **Check for unstored calculations and summary fields used in finds, sorts, or portal filters.** These force FileMaker to evaluate every record on the fly instead of using an index — the single most common cause of a script that used to be fast slowing down as a table grows from 5,000 to 500,000 records.\n- **Look at portal filtering and unindexed relationships.** A portal with a filter expression re-evaluates the filter for every related record every time the layout refreshes — fine at 50 related records, painful at 5,000.\n- **Check container field storage.** Storing large files (scans, photos, PDFs) directly inside the database file instead of as external secure storage bloats the file, slows backups, and slows every operation that touches that table.\n- **Review recently added triggers.** An OnRecordCommit or OnLayoutEnter script trigger that seemed harmless when added can quietly run on every navigation once user volume grows.\n\n## Can AI tools help you diagnose performance issues faster?\n\nYes — and this is increasingly practical rather than experimental. Tools like Claris's klai (AI built directly into the FileMaker platform) can be pointed at server logs, statistics exports, or even schema and script text, and asked to spot patterns a human would need hours to find manually — for example, flagging which scripts reference unstored calculations, or summarizing which time windows show the highest elapsed-time spikes across weeks of statistics logs.\n\nUsed well, AI doesn't replace the diagnostic process above — it speeds up the pattern-recognition part of it, turning a day of manually scanning log exports into a few minutes of guided analysis. It's especially useful when a system has grown organically over years and no single person on the team fully remembers every script and trigger anymore.\n\n## Could a layout or interface add-on be the real cause, not the database?\n\nIt's worth checking, because not every \"slow\" complaint is a database performance problem at all. Interface layers and web-rendering add-ons — for example FmBetterforms, used to build modern, browser-style forms and layouts inside FileMaker — render additional HTML\u002FCSS\u002FJS on top of the native layout engine. If a form built this way feels sluggish, the cause might be:\n\n- A heavy or unoptimized custom layout\u002Ftheme rendering many elements at once\n- The add-on making its own web-viewer-based calls back to the database on every keystroke or field change\n- The client machine's browser engine (used internally by the add-on) being under-resourced\n\nBefore assuming the whole database is slow, test the same action on a plain native FileMaker layout without the add-on. If it's fast there, the issue is in how the interface layer was configured, not in the schema or server.\n\n\n\n## What's a good step-by-step diagnostic checklist to follow?\n\n1. Reproduce the issue and note exact time, user, and action.\n2. Test the same action locally, remotely, and from another user's machine.\n3. Check FileMaker Server Admin Console statistics and cache hit ratio.\n4. Review scheduled scripts and backup timing for overlaps.\n5. Check the Clients tab for stuck or long-running sessions.\n6. Log elapsed time at key script steps to isolate the slow section.\n7. Search for unstored calculations, unindexed fields, and portal filters in the slow area.\n8. Check container field storage settings.\n9. Test the same action without any interface add-on layer (like FmBetterforms) to rule out the rendering layer.\n10. If the system has grown complex, consider AI-assisted log analysis (e.g. via klai) to spot patterns across weeks of data.\n\n## FAQ: quick answers to common diagnostic questions\n\n**Does adding more RAM to FileMaker Server always fix performance problems?**\nSometimes, but not always. It helps when the Statistics tab shows a consistently low cache hit ratio, but it won't fix an unstored calculation being searched on every record, or a network latency problem for remote users.\n\n**Should we just move to a bigger\u002Ffaster server?**\nOnly after you've confirmed the bottleneck is actually server capacity, not schema design, script logic, or network conditions. Upgrading hardware to solve a schema problem usually just delays the same complaint by a few months.\n\n**How often should we check server statistics, even when things feel fine?**\nMonthly, at minimum — and always before and after a major schema change, a large data migration, or onboarding a new group of users. Catching a slowly rising elapsed-time trend early is much cheaper than reacting to a full outage complaint.\n\n**Is it normal for performance to degrade as the database grows?**\nSome degradation is expected as record counts grow, but a well-indexed, well-structured system should degrade gracefully, not suddenly. A sudden cliff usually points to something specific — like a table crossing a size threshold that exposes an unstored calculation that was never noticed before.\n\nDiagnosing performance problems properly is really the first half of a bigger job — once you know the real cause, the fix often ties directly into the structural choices covered in [how to improve the performance and structure of a FileMaker solution](https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fhow-to-improve-the-performance-and-structure-of-a-filemaker-solution). If your team has reached the point of guessing rather than measuring, Loggix can help — whether that means a hands-on performance audit, restructuring a FileMaker solution that's outgrown its original design, connecting it to other systems through cleaner APIs, or adding AI-assisted diagnostics into your day-to-day workflow.","\u003Cp>Your FileMaker system used to feel instant. Now a layout that opened in half a second takes three or four, a nightly import that used to finish before anyone arrived at the office is still running at 9am, and your team has started joking about "the system being slow again" instead of reporting it as a real problem. Everyone has a theory — the server, the internet, "that new script," too many users — but nobody has actually measured anything.\u003C\u002Fp>\n\u003Cp>This article walks through how to actually diagnose a slow FileMaker system, step by step, before you spend money on a bigger server or a rewrite you may not need.\u003C\u002Fp>\n\u003Ch2>Why does "it feels slow" almost never point to the real cause?\u003C\u002Fh2>\n\u003Cp>"Slow" is a symptom, not a diagnosis. A layout that takes 4 seconds to load could be caused by:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>A poorly indexed field being searched on every record load\u003C\u002Fli>\n\u003Cli>A script running unstored calculations across 40,000 related records\u003C\u002Fli>\n\u003Cli>A remote user in another country connecting over a VPN with high latency\u003C\u002Fli>\n\u003Cli>A container field storing full-resolution PDFs directly in the database\u003C\u002Fli>\n\u003Cli>Another script, kicked off by someone else, hammering the same table at the same moment\u003C\u002Fli>\n\u003Cli>FileMaker Server itself running low on RAM or CPU because a backup and a scheduled script overlap\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Each of these needs a completely different fix. Guessing wastes time and, worse, sometimes makes things worse — for example, adding indexes randomly can bloat the file and slow down writes without ever touching the actual bottleneck.\u003C\u002Fp>\n\u003Ch2>Where should you start looking first: client, network, or server?\u003C\u002Fh2>\n\u003Cp>Before touching any code, isolate where the delay actually happens. A simple, reliable first test:\u003C\u002Fp>\n\u003Col>\n\u003Cli>Have the affected user reproduce the slow action.\u003C\u002Fli>\n\u003Cli>Have someone in the same office, on the same network, try the identical action at the same moment.\u003C\u002Fli>\n\u003Cli>Have someone connecting remotely (VPN or over the internet) try it too.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>If only the remote user is slow, you're likely looking at network latency or bandwidth, not a server or schema problem — a very common situation with teams that grew from one office to multiple locations or added home-working staff without revisiting their connection setup.\u003C\u002Fp>\n\u003Cp>If everyone is slow at the same time, the problem is on the server or in the file itself.\u003C\u002Fp>\n\u003Cp>If it's slow for one specific user only, check that user's machine: available RAM, disk space, whether antivirus software is scanning FileMaker's cache folder, or whether they're running an outdated FileMaker Pro client version against a newer server.\u003C\u002Fp>\n\u003Ch2>What should you check first on FileMaker Server itself?\u003C\u002Fh2>\n\u003Cp>FileMaker Server ships with built-in diagnostic tools that are underused. Start here before installing anything new:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>The Statistics tab in the Admin Console\u003C\u002Fstrong> — shows elapsed time, I\u002FO, and cache hit percentages per database. A cache hit ratio consistently below roughly 90-95% is a strong signal the server doesn't have enough RAM allocated for the size of your file.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Server-side statistics logging\u003C\u002Fstrong> — enable it and let it run for a day. It logs per-database read\u002Fwrite counts, network I\u002FO, and elapsed time in intervals you choose, so you can correlate a slowdown with a specific time of day (e.g. every day at 2pm, right when the scheduled import runs).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>The Clients tab\u003C\u002Fstrong> — shows exactly who is connected and what they're doing right now. If one user's session is stuck in a long-running script, you'll see it here immediately.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Progressive backups and scheduled scripts overlapping\u003C\u002Fstrong> — a very common, completely invisible cause of slowdowns. If your nightly backup, a scheduled server-side script, and a scheduled import all fire within the same 10-minute window, every user connected during that window feels it, and nobody thinks to check the schedule.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2>How do you find the specific script or layout causing the slowdown?\u003C\u002Fh2>\n\u003Cp>Once you know the problem is server-side or file-side, narrow it down further:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Enable the Data Viewer's script debugger with timestamps\u003C\u002Fstrong>, or better, wrap suspect scripts with \u003Ccode>Get ( CurrentTimeUTCMilliseconds )\u003C\u002Fcode> logging at key steps and write the results to a log table. This turns "the import feels slow" into "step 14, the unstored calculation on the LineItems table, takes 8 of the 11 seconds."\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Check for unstored calculations and summary fields used in finds, sorts, or portal filters.\u003C\u002Fstrong> These force FileMaker to evaluate every record on the fly instead of using an index — the single most common cause of a script that used to be fast slowing down as a table grows from 5,000 to 500,000 records.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Look at portal filtering and unindexed relationships.\u003C\u002Fstrong> A portal with a filter expression re-evaluates the filter for every related record every time the layout refreshes — fine at 50 related records, painful at 5,000.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Check container field storage.\u003C\u002Fstrong> Storing large files (scans, photos, PDFs) directly inside the database file instead of as external secure storage bloats the file, slows backups, and slows every operation that touches that table.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Review recently added triggers.\u003C\u002Fstrong> An OnRecordCommit or OnLayoutEnter script trigger that seemed harmless when added can quietly run on every navigation once user volume grows.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Can AI tools help you diagnose performance issues faster?\u003C\u002Fh2>\n\u003Cp>Yes — and this is increasingly practical rather than experimental. Tools like Claris's klai (AI built directly into the FileMaker platform) can be pointed at server logs, statistics exports, or even schema and script text, and asked to spot patterns a human would need hours to find manually — for example, flagging which scripts reference unstored calculations, or summarizing which time windows show the highest elapsed-time spikes across weeks of statistics logs.\u003C\u002Fp>\n\u003Cp>Used well, AI doesn't replace the diagnostic process above — it speeds up the pattern-recognition part of it, turning a day of manually scanning log exports into a few minutes of guided analysis. It's especially useful when a system has grown organically over years and no single person on the team fully remembers every script and trigger anymore.\u003C\u002Fp>\n\u003Ch2>Could a layout or interface add-on be the real cause, not the database?\u003C\u002Fh2>\n\u003Cp>It's worth checking, because not every "slow" complaint is a database performance problem at all. Interface layers and web-rendering add-ons — for example FmBetterforms, used to build modern, browser-style forms and layouts inside FileMaker — render additional HTML\u002FCSS\u002FJS on top of the native layout engine. If a form built this way feels sluggish, the cause might be:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>A heavy or unoptimized custom layout\u002Ftheme rendering many elements at once\u003C\u002Fli>\n\u003Cli>The add-on making its own web-viewer-based calls back to the database on every keystroke or field change\u003C\u002Fli>\n\u003Cli>The client machine's browser engine (used internally by the add-on) being under-resourced\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Before assuming the whole database is slow, test the same action on a plain native FileMaker layout without the add-on. If it's fast there, the issue is in how the interface layer was configured, not in the schema or server.\u003C\u002Fp>\n\u003Ch2>What's a good step-by-step diagnostic checklist to follow?\u003C\u002Fh2>\n\u003Col>\n\u003Cli>Reproduce the issue and note exact time, user, and action.\u003C\u002Fli>\n\u003Cli>Test the same action locally, remotely, and from another user's machine.\u003C\u002Fli>\n\u003Cli>Check FileMaker Server Admin Console statistics and cache hit ratio.\u003C\u002Fli>\n\u003Cli>Review scheduled scripts and backup timing for overlaps.\u003C\u002Fli>\n\u003Cli>Check the Clients tab for stuck or long-running sessions.\u003C\u002Fli>\n\u003Cli>Log elapsed time at key script steps to isolate the slow section.\u003C\u002Fli>\n\u003Cli>Search for unstored calculations, unindexed fields, and portal filters in the slow area.\u003C\u002Fli>\n\u003Cli>Check container field storage settings.\u003C\u002Fli>\n\u003Cli>Test the same action without any interface add-on layer (like FmBetterforms) to rule out the rendering layer.\u003C\u002Fli>\n\u003Cli>If the system has grown complex, consider AI-assisted log analysis (e.g. via klai) to spot patterns across weeks of data.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2>FAQ: quick answers to common diagnostic questions\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Does adding more RAM to FileMaker Server always fix performance problems?\u003C\u002Fstrong>\nSometimes, but not always. It helps when the Statistics tab shows a consistently low cache hit ratio, but it won't fix an unstored calculation being searched on every record, or a network latency problem for remote users.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Should we just move to a bigger\u002Ffaster server?\u003C\u002Fstrong>\nOnly after you've confirmed the bottleneck is actually server capacity, not schema design, script logic, or network conditions. Upgrading hardware to solve a schema problem usually just delays the same complaint by a few months.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>How often should we check server statistics, even when things feel fine?\u003C\u002Fstrong>\nMonthly, at minimum — and always before and after a major schema change, a large data migration, or onboarding a new group of users. Catching a slowly rising elapsed-time trend early is much cheaper than reacting to a full outage complaint.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Is it normal for performance to degrade as the database grows?\u003C\u002Fstrong>\nSome degradation is expected as record counts grow, but a well-indexed, well-structured system should degrade gracefully, not suddenly. A sudden cliff usually points to something specific — like a table crossing a size threshold that exposes an unstored calculation that was never noticed before.\u003C\u002Fp>\n\u003Cp>Diagnosing performance problems properly is really the first half of a bigger job — once you know the real cause, the fix often ties directly into the structural choices covered in \u003Ca href=\"https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fhow-to-improve-the-performance-and-structure-of-a-filemaker-solution\">how to improve the performance and structure of a FileMaker solution\u003C\u002Fa>. If your team has reached the point of guessing rather than measuring, Loggix can help — whether that means a hands-on performance audit, restructuring a FileMaker solution that's outgrown its original design, connecting it to other systems through cleaner APIs, or adding AI-assisted diagnostics into your day-to-day workflow.\u003C\u002Fp>\n","Jeroen","2026-07-24",1784901677000,[19,20,21,22,23,24,25],"FileMaker performance","FileMaker Server diagnostics","FileMaker troubleshooting","klai","FmBetterforms","database performance tuning","Claris FileMaker","\u002Fapi\u002Fknowledge\u002Fimage\u002F382\u002F?v=c01a3a4dceb9",false,"",null,{"title":31,"slug":32},"FileMaker and Claris","filemaker-and-claris",{"title":34,"slug":35},"How to improve the performance and structure of a FileMaker solution","how-to-improve-the-performance-and-structure-of-a-filemaker-solution"]