How to Choose the Right Auto-Refresh Interval for Your WordPress Table

Updated July 2026 • 6 min read • By Fahad Murtaza • By Fahad Murtaza

Auto-refresh keeps your WordPress data tables current without requiring users to reload the page, but choosing the wrong interval can silently hurt your server and frustrate your audience. This guide walks through the trade-offs, explains how TableCrafter's AJAX-based auto-refresh works under the hood, and gives you a concrete framework for picking an interval that fits your actual use case. WordPress powers 43% of all websites globally (W3Techs, July 2026), and TableCrafter bridges the gap between the data you collect and the tables your users need to see, no custom PHP, no dashboard access required for viewers. The free version on WordPress.org supports CSV, JSON, Google Sheets, and Excel. Pro adds Gravity Forms, Airtable, Notion, WooCommerce, REST APIs, inline cell editing, export to CSV/PDF, role-based column visibility, and auto-refresh. Every table embeds on any page with a [tablecrafter] shortcode or the native Gutenberg block. Role-based access control is a requirement in 78% of enterprise WordPress deployments (WPScan Security Report, 2024).

What Auto-Refresh Actually Does in TableCrafter?

TableCrafter's auto-refresh feature is a Free capability, available on both the free plan and Pro, that polls your WordPress server on a fixed timer. Each tick fires an AJAX request to wp-admin/admin-ajax.php, which performs nonce validation and capability checks before querying your data source, whether that is Gravity Forms entries, a Google Sheets feed, a REST API endpoint, or an Airtable base. The response replaces the current table contents in the DOM without a full page reload.

Because every refresh is a real authenticated request, it carries the same overhead as a user loading the table for the first time: a PHP bootstrap, a database query (or external API call), JSON encoding, and the round-trip latency back to the browser. Multiply that by the number of concurrent visitors and you can see why interval selection matters far more than it appears at first glance.

What Is the Two Variables That Govern Your Decision?

Every interval decision is a tension between two factors: data freshness requirements and server cost tolerance. Neither can be ignored.

Data freshness is driven by how quickly stale data causes a real problem for your users. A logistics dashboard showing truck locations where dispatchers make routing decisions every few minutes has a much tighter tolerance than a leaderboard that updates once per hour.

Server cost is driven by concurrent users times requests per minute. Ten users refreshing every 10 seconds generates 60 requests per minute. One hundred users doing the same generates 600, that is ten requests per second hitting your database before any caching layer gets involved.

How Does Interval Recommendations by Use Case Work?

There is no single correct answer, but the following ranges cover the vast majority of real-world WordPress table deployments.

Every 10–30 seconds, Live operational data

Use this range only when users are making time-sensitive decisions based on the data. Examples include active order queues, support ticket inboxes, or load-tracking dashboards where a dispatcher needs to know a driver's current status within the last half-minute. At this cadence you should have object caching (Redis or Memcached) in place and should limit the table to the minimum number of rows needed. Use TableCrafter's per-page pagination setting to constrain each AJAX response to only the rows visible in the viewport.

Every refresh fires a full authenticated request through wp-admin/admin-ajax.php: PHP bootstrap, capability check, database query, JSON encoding, and network round-trip. At a 10-second interval with 20 concurrent users that is 120 PHP invocations per minute from this single table. If your host has a PHP process limit of 20 to 30, you will hit contention quickly. Pair this interval only with tables that have tight row counts, active role restrictions to limit the concurrent viewer pool, and server-side response caching configured in the table's Performance tab.

Every 60–120 seconds, Near-real-time monitoring

This is the most common sweet spot for tables that need to feel live without creating unsustainable server load. Inventory counts, form submission tallies, or internal reporting dashboards fit well here. Most shared hosting environments can handle this range comfortably for up to roughly 50 concurrent viewers without dedicated object caching, because one AJAX request per minute per user is well within the capacity of a standard PHP-FPM or mod_php configuration.

At a 60-second interval, a user who submits a Gravity Forms entry will see the new row appear in the table within one minute with no manual action. For most collaborative data-entry workflows, one-minute latency is imperceptible as a real-time delay.

Pair this range with the last-updated indicator enabled in the table's Display Settings. The indicator shows the exact timestamp of the most recent successful refresh below the table, giving users confidence that the data is current without them needing to count seconds or reload the page manually. The refresh_last_updated attribute controls this visibility; it defaults to showing, so it is visible unless you explicitly disable it in the table builder.

Every 5–15 minutes, Periodic updates

If your underlying data changes a few times per hour at most, intervals in this range are both sufficient and courteous to your server. Gravity Forms entry tables that aggregate weekly survey responses, WooCommerce order summaries, or Airtable-backed project status boards are good candidates. At a 5-minute interval with 100 concurrent users you are generating just 20 requests per minute, easily manageable on most managed WordPress hosts without any additional caching infrastructure.

This range is also the right default if you are enabling auto-refresh for the first time and are not yet sure how much server load to expect. Start at 300 seconds (5 minutes) in the table's Display Settings, monitor your hosting control panel's PHP request rate graph for a few days, and shorten the interval only if you confirm the server can absorb the additional load.

For external data sources such as Airtable or Google Sheets, setting your table to this interval and also configuring an API response cache in the Performance tab prevents the external API from receiving a request on every refresh cycle. With a 2-minute transient cache and a 5-minute refresh interval, the external API receives at most one call per cache expiry rather than one per refresh cycle, keeping your integration safely within rate limits.

Manual refresh only, Static or infrequently updated data

If your data changes less than a few times per day, auto-refresh adds server cost with no real user benefit. Consider leaving the auto_refresh_interval set to 0 (off) in the table builder and relying on the shortcode's standard page-load render. The table reflects the current data every time a visitor loads the page, which is sufficient for static or slowly changing datasets.

Auto-refresh is available on both the free plan and Pro. Setting the interval to 0 disables polling entirely, which is the correct default for content pages where the underlying data changes daily or less frequently. A common mistake is enabling a low interval during initial testing to confirm the feature works, then forgetting to raise it before the page goes live to real traffic.

Treat the auto_refresh_interval setting as a configuration value that requires deliberate cost analysis rather than a convenience toggle. If you discover an interval was set too low after the fact, navigate to TableCrafter → Tables, edit the affected table, change the interval in Display Settings, and save. The new interval takes effect on the next page load, with no shortcode changes required.

How Do I Configure Auto-Refresh in TableCrafter?

Auto-refresh is configured per table inside the table builder. Navigate to TableCrafter → Tables, open the table you want to configure, and look for the Display Settings tab. The auto_refresh_interval field accepts a value in seconds: enter 0 to disable polling, or a minimum of 5 to enable it. Values below 5 are clamped to 5 on save.

Additional settings in the same tab control the refresh experience for users. The refresh indicator shows a brief loading spinner during each poll. The refresh_last_updated setting shows a timestamp below the table after each successful refresh (visible by default). The countdown option shows the time remaining until the next refresh for users who want that signal.

Once saved, embed the table on any page or post using the standard shortcode:

[tablecrafter id="42"]

The auto-refresh configuration is stored server-side against the table ID. You do not need to pass any interval parameter in the shortcode itself. The JavaScript polling module reads the configuration from a data attribute on the wrapper element and manages the timer client-side, pausing automatically when the browser tab is in the background to avoid unnecessary server load from hidden tabs.

How Does Server-Side Factors That Shift Your Target Interval Work?

Your hosting environment has a significant influence on how aggressive you can be with refresh intervals. The following conditions allow you to push toward shorter intervals safely:

• Object caching enabled (Redis, Memcached), repeated identical queries hit memory instead of the database, dramatically reducing per-request cost.
• External data sources (Google Sheets, REST API, Airtable), TableCrafter can cache the external response between refreshes, meaning a 30-second table interval does not necessarily mean 30-second API calls to a rate-limited third party.
• Small result sets, a table returning 20 rows is meaningfully cheaper to serve than one returning 500. Use pagination and TableCrafter's advanced filter settings to constrain result size before tuning the interval.
• Role-based permissions Pro, if your table is restricted to logged-in users with a specific role, your realistic concurrent viewer count is much lower than a public-facing table, which shifts the load math in your favor.

Conversely, the following conditions should push you toward longer intervals or disabling auto-refresh:

• Shared hosting with no object cache and a connection limit below 50
• Tables with complex JOINs or lookup field resolution across many rows
• External API sources with rate limits (Airtable's free tier, for example, limits requests per second)
• Tables using email alerts on data changes Pro, if the alert logic runs on every refresh cycle rather than on write, the interval directly controls how often that logic executes

How Do Testing and Validating Your Chosen Interval Work?

After setting an interval, do not assume it is correct, validate it. Open your browser's network panel while the table is live on the page and confirm the AJAX requests are firing at the expected cadence and returning HTTP 200 with a reasonable payload size. A response larger than roughly 100 KB for a standard table view is a signal to reduce your row count or enable pagination before shortening the interval further.

For server-side validation, check your hosting control panel's PHP request rate graph before and after enabling auto-refresh. If you do not have access to that, a simple approach is to enable WordPress's built-in query logging temporarily and count how many queries the refresh handler generates per request. Multiply that by your expected concurrent users and your chosen interval to estimate queries per minute.

If you find your chosen interval is causing visible server strain, the fastest remediation is to double the interval before investigating caching or query optimization. Halving your requests per minute is always faster to deploy than an infrastructure change.