How to monitor a business-critical application

You find out your order-processing system is down when a warehouse employee calls to say they can't print picking lists. Or a customer emails asking why their invoice never arrived — and only then do you discover the nightly sync between FileMaker and your accounting package silently failed three days ago. If the first sign of a problem is a phone call from someone whose work just stopped, you don't have monitoring — you have hope.

This article explains what it actually means to monitor a business-critical application, what to track, which tools fit a FileMaker-based environment, and how to build a monitoring habit that catches problems before your users do.

What does "monitoring a business-critical application" actually mean?

Monitoring is not the same as backups, and it's not the same as maintenance. Backups protect your data if something goes wrong. Maintenance keeps the software up to date. Monitoring is the layer that tells you something is going wrong right now, or about to — ideally before anyone downstream notices.

For a system like a custom FileMaker application, an ERP core, or an API integration between systems, monitoring typically covers three layers:

1. Infrastructure health — is the server up, is there enough disk space, is CPU/memory within normal range?
2. Application behavior — are scheduled scripts running on time, are integrations completing successfully, are error logs staying quiet?
3. Business outcomes — are orders actually flowing through, are invoices actually being generated, is data actually arriving where it should?

Most companies only monitor layer one, if that. The expensive failures almost always happen in layers two and three — the sync job that runs but silently drops records, the script that errors out at 2am with nobody watching.

Why does this matter more for FileMaker and custom systems than for off-the-shelf software?

With a SaaS product like Salesforce or Exact Online, the vendor monitors their own infrastructure — you only need to watch your side of the integration. With a custom-built FileMaker solution, an in-house ERP, or a bespoke API connector, there is no vendor dashboard watching it for you. You are the vendor, whether that's an internal developer or an external partner like Loggix.

That's not a downside of custom software — it's simply a responsibility that comes with owning something tailored to your business instead of renting a generic tool. The trade-off is worth it: a system built around your actual workflow, but only if someone is actually watching it run.

What should you actually monitor?

Not everything needs the same level of attention. A useful way to decide is to ask: if this stopped working silently, how long before someone notices — and what would it cost by then?

Here's a practical breakdown for a typical FileMaker or integrated business system:

• Scheduled scripts and server-side automations — nightly imports, invoice generation, data syncs with Exact Online, Shopify, or a webshop. If a scheduled script fails silently, nobody knows until the missing data becomes a business problem days later.
• API connectors — every integration point (FileMaker ↔ accounting, FileMaker ↔ webshop, FileMaker ↔ a supplier's system) is a place where authentication tokens expire, endpoints change, or rate limits get hit.
• Server resources — disk space (FileMaker containers and logs fill up faster than people expect), CPU spikes during peak hours, memory leaks after a bad update.
• User-facing performance — is the layout that used to load in 1 second now taking 8 seconds? Slowness is often the earliest warning sign of a deeper problem.
• Error logs — FileMaker Server's Event Viewer, script error logs, and plug-in error output. Most of this data already exists; almost nobody reads it regularly.
• License and certificate expiry — SSL certificates, ODBC/JDBC credentials, third-party API keys. These fail predictably and are entirely preventable.
• Backup completion and integrity — a backup schedule that's "on" isn't the same as backups that are actually completing and restorable.

How do you monitor a FileMaker-based system in practice?

You don't need to build a monitoring platform from scratch. In most Loggix implementations, monitoring is layered using a mix of native tools and lightweight custom additions:

1. Use FileMaker Server's built-in tools first. The Admin Console and Event Viewer already log server errors, backup status, and connection counts. Most teams never open them until something breaks — schedule a weekly five-minute check instead.
2. Build a scripted health-check layout inside the solution itself. A simple admin layout that shows last-run timestamps for every scheduled script, record counts from the last sync, and any errors caught by try/catch blocks gives you a business-level view, not just a server-level one.
3. Log errors to a dedicated table, not just to a text file. A FileMaker table of timestamped errors (script name, error code, affected record) is searchable, reportable, and can trigger a notification script.
4. Send alerts, don't wait for reports. A script step that emails or Slack-notifies an admin the moment a scheduled import fails is worth more than any dashboard nobody checks. Even a simple "send email if error code ≠ 0" step catches most silent failures.
5. Use external uptime monitoring for anything web-facing. If part of the solution is exposed via FileMaker WebDirect, Klai (a chat/AI interface layered on FileMaker), or FmBetterforms (for building modern web forms and portals on top of FileMaker), tools like UptimeRobot or Pingdom can ping those endpoints and alert you within minutes of downtime.
6. Monitor AI components separately. If you've added an AI layer to a FileMaker workflow — for example using Klai to let staff query data conversationally — treat the underlying API calls (to OpenAI, Claude, or another provider) as their own integration point. Track failed calls, rate-limit errors, and unexpected cost spikes just as you would any other API.
7. Review logs on a schedule, not reactively. Weekly for error logs, monthly for disk space and license expiry, quarterly for a full health review of every scheduled process.

What's the difference between monitoring and alerting?

Monitoring collects the data; alerting decides who gets told, when, and how urgently. A monitoring setup that produces logs nobody reads is barely better than no monitoring at all.

A good rule: every monitored item needs an owner and a threshold. "Disk space" isn't useful — "IT manager gets an email when server disk space drops below 15%" is. "Sync errors" isn't useful — "admin gets a Slack message within 5 minutes if the Exact Online sync fails" is.

Set severity levels so people aren't drowning in noise:

• Critical (immediate alert, any hour): production system down, backup failed, core integration broken.
• Warning (alert during business hours): disk space trending low, a non-critical script failed once, response times degrading.
• Informational (weekly digest): successful backup confirmations, routine log summaries.

How often should you actually check on things?

Frequency	What to check
Real-time (automated alerts)	Server uptime, critical script failures, integration errors
Daily	Error log summary, backup confirmation
Weekly	Disk space trend, script performance, WebDirect/portal uptime history
Monthly	License/certificate expiry dates, user access review, storage growth
Quarterly	Full monitoring setup review — are the right things still being watched?

What are common monitoring mistakes companies make?

• Treating backups as monitoring. A completed backup log doesn't confirm the backup is restorable — test restores periodically.
• Monitoring the server but not the business process. A server can be perfectly healthy while an integration quietly drops 10% of records due to a data-mapping mismatch.
• Alert fatigue. Sending every warning to everyone trains people to ignore alerts entirely. Fewer, better-targeted alerts beat a flooded inbox.
• No named owner. If an alert fires and three people assume someone else is handling it, nobody is.
• Set-and-forget setups. Monitoring configured two years ago for a solution that's since changed (new integrations, new scripts, new servers) often has blind spots nobody's noticed yet.

Checklist: is your business-critical application actually monitored?

• Every scheduled script logs its last run time and success/failure status
• Every API integration has error handling that logs and alerts on failure
• Disk space, CPU, and memory are tracked with defined alert thresholds
• SSL certificates and API keys have expiry dates tracked with advance warning
• Backups are not just completing but periodically test-restored
• Alerts have a named owner and a response expectation
• Web-facing components (WebDirect, portals, AI interfaces) have external uptime checks
• Logs are reviewed on a set schedule, not only after something breaks

FAQ

Do I need special software to monitor a FileMaker system? Not necessarily. Much of it can be built with native FileMaker scripting, the Admin Console, and free external uptime tools. Dedicated monitoring platforms make sense once you have many integrations or multiple servers to watch.

Who should be responsible for monitoring — IT, the developer, or the business owner? Ultimately the business owner needs to know it's happening, but day-to-day ownership usually sits with whoever maintains the system technically — an in-house IT manager or an external development partner. The key is that responsibility is explicit, not assumed.

How is this different from general IT maintenance? Maintenance is proactive upkeep — updates, patches, performance tuning. Monitoring is the feedback loop that tells you when maintenance is needed or when something has already broken. They work together; neither replaces the other. This topic connects closely to the broader question of how to secure and maintain business-critical software, which covers the maintenance side in more depth.

Can AI help with monitoring? Yes, increasingly. AI layers like Klai can be used not just to query data conversationally but also to summarize error logs in plain language or flag anomalies a human might scroll past. It's not a replacement for proper alerting, but it can make logs more usable for non-technical staff.

Where do you go from here?

Monitoring a business-critical application isn't a one-time project — it's an ongoing discipline that scales with how much your business depends on the system. The good news is that most of the groundwork (logging, error handling, health-check layouts) can be built directly into a FileMaker solution rather than bolted on afterward.

If you're not sure whether your current setup would actually catch a silent failure before your customers do, that's worth a closer look. Loggix can help review an existing FileMaker or integrated system for monitoring gaps, build in proper error logging and alerting, connect external uptime checks for web-facing components like WebDirect or FmBetterforms portals, or add an AI layer such as Klai to make logs and alerts easier for your team to act on. Sometimes the most valuable step is simply a short consultancy session to map out where your current blind spots are before they become a 2am phone call.