How to Auto-Refresh Live Data in a WordPress Table

Updated July 2026 • 6 min read • By Fahad Murtaza

TableCrafter's auto-refresh feature polls your data source at a set interval and silently updates the table, no page reload, no flash, no lost scroll position. This is what makes a REST API-powered table feel like a live dashboard rather than a static report. Auto-refresh is available on all plans including free (confirmed in issue #1743). 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, and no per-row limits on the free tier. 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 and Excel, and role-based column visibility. Every table embeds on any page with a [tablecrafter] shortcode or the native Gutenberg block.

How Does Auto-Refresh Work?

A table refreshing every 10 seconds on a page with 500 daily visitors generates over 4.3 million AJAX requests per day — TableCrafter batches these into a single lightweight JSON poll rather than full page reloads.

When auto-refresh is enabled, the frontend JavaScript running on the visitor's browser sends an XHR (XMLHttpRequest) to a WordPress AJAX endpoint at the configured interval. That endpoint fetches fresh data from your data source, whether that is a REST API endpoint, Gravity Forms entries, or another source, and returns the serialized rows as JSON. The table re-renders with the new data without touching the URL bar, the browser history, or the rest of the page.

The re-render is diff-aware: TableCrafter compares the incoming rows to the currently displayed rows and only updates cells that have changed. This prevents the entire table from flickering on each poll cycle.

The auto-refresh cycle is implemented using setInterval in the browser. If the previous fetch has not completed before the next interval fires, the pending request is skipped, the table does not stack up multiple simultaneous requests to the same endpoint.

How Do I Enable Auto-Refresh?

In the table builder at TableCrafter → Tables, open the Display tab and locate the Auto-Refresh section. Toggle it on and set the interval.

Available interval presets:

• 10 seconds, very aggressive; suitable only for critical real-time monitoring
• 30 seconds, good default for most live dashboards
• 60 seconds, balanced; appropriate for data that changes every few minutes
• 5 minutes, conservative; suitable for data updated infrequently
• Custom, enter any number of seconds

The minimum allowed interval is 5 seconds. Values below 5 seconds are rejected at save time. There is no maximum, but intervals above 3600 seconds (1 hour) are unusual, you would typically disable auto-refresh entirely and let users reload manually for data that changes that rarely.

What Is the Last-Updated Timestamp?

Enable Show Last Updated Timestamp in the same Auto-Refresh section. When enabled, a line appears below the table in the format:

Last updated: June 23, 2026 at 2:45:12 PM

The timestamp updates every time a successful refresh completes. If a refresh request fails (network error, API timeout, HTTP 5xx from the data source), the timestamp is not updated and a subtle warning indicator appears: "Update failed – retrying". The table continues displaying the last successfully fetched data.

You can customize the timestamp format by adding a filter in your theme's functions.php:

add_filter('tablecrafter_last_updated_format', function($format) {
  return 'H:i:s'; // 24-hour time only
});

How Do Auto-Refresh and User Interactions Work?

TableCrafter pauses the auto-refresh cycle while a user is interacting with inline edit fields. If a user has clicked into a cell to edit a value, the refresh timer is paused to prevent the table from re-rendering and losing the user's unsaved input. Once the edit is saved or cancelled, the refresh cycle resumes from the beginning of the interval.

Sorting, filtering, and searching also interact with auto-refresh in a predictable way: the refresh re-applies the current sort and filter state to the new data. If a user has filtered the table to show only rows where status equals "operational", the refreshed data will also be filtered, rows that were previously hidden will not suddenly appear unless the filter explicitly matches them.

How Do Auto-Refresh and Data Source Caching Work?

If you have configured a cache TTL on your REST API data source, for example a 60-second cache, the auto-refresh interval should be set to the same value or longer. Setting auto-refresh to 30 seconds when the data source caches responses for 60 seconds means half of your refresh requests will return stale cached data. This is not harmful, but it means the display will not update more frequently than the cache TTL regardless of the refresh interval.

For live dashboards where you need the freshest possible data, either disable data source caching or set the cache TTL to a value lower than or equal to the refresh interval.

How Do Battery and Bandwidth Considerations Work?

On desktop browsers and stable Wi-Fi connections, even aggressive refresh intervals (10–30 seconds) have negligible performance impact. On mobile devices and battery-constrained environments, the calculation is different.

A 10-second refresh interval keeps the browser's networking layer active continuously, preventing the device's radio from entering a low-power state. On modern mobile devices, continuous network polling is one of the primary causes of battery drain from web pages.

TableCrafter respects the browser's Page Visibility API: when the user switches tabs or the browser goes to the background, the auto-refresh timer is paused automatically. It resumes when the page becomes visible again. This is a significant battery and bandwidth optimization, the table will not poll in the background while the user is on another tab.

For public-facing dashboards that should be efficient on mobile, prefer 60-second or longer intervals. If sub-minute freshness is a hard requirement, consider server-sent events (SSE) or WebSockets rather than polling, though those require a different integration approach than TableCrafter's built-in auto-refresh.

How Do I Enable Auto-Refresh from the Shortcode?

For tables configured in the table builder, auto-refresh settings (interval, indicator, last-updated display) are stored in the table's saved configuration and applied automatically to every embed of that table. The [tablecrafter id="5"] shortcode reads the saved config on each page load; no extra shortcode attributes are needed to activate auto-refresh once it is configured in the builder. The interval is a table-level setting only, you cannot override it inline via the shortcode.

The following shortcode attributes control display behavior, not the interval, and work independently of the table builder's settings:

• refresh_indicator="false": hides the spinning indicator that appears while a refresh is in flight
• refresh_countdown="true": shows a countdown to the next refresh cycle
• refresh_last_updated="false": hides the "Last updated:" timestamp line

How Do I Disable Auto-Refresh for Specific Embeds?

There is no shortcode attribute that turns off the table-builder's configured auto-refresh for a specific embed. Auto-refresh is part of the saved table configuration, and the shortcode faithfully loads that configuration. If you need a non-refreshing version of the same table on a specific page (such as a print-friendly view or a slow-server context), the correct approach is to create a duplicate table configuration with auto-refresh disabled and embed that configuration's ID on the page in question.

The Gutenberg block has a dedicated Auto-Refresh toggle in the block sidebar that overrides the table-level setting for that block instance. If your site uses the Gutenberg block editor and you need per-embed control, prefer the block over the shortcode.

Which Auto-Refresh Interval Should I Choose?

The right interval depends on how fast your underlying data changes and how much server load the polling will generate. Each auto-refresh fires a background request from every visitor's browser to your WordPress server — on a high-traffic public page, a 10-second interval across 200 concurrent visitors is 1,200 requests per minute. Size the interval to your actual update frequency, not your preference for "live":

• 10s — Real-time monitoring only. Use for authenticated internal ops dashboards where an operator is watching for immediate status changes. Never use on public or high-traffic pages.
• 30s — Standard live dashboard. Operational status boards, live order queues, dispatch views. Acceptable on low-traffic authenticated pages.
• 60s — Good general default. Metrics dashboards, live inventory counts, leaderboards. Balances freshness with server load for moderate-traffic pages.
• 5 min — Semi-live data. Reporting tables, public-facing leaderboards, team dashboards. Appropriate for most public pages where visitors expect near-real-time but not instant updates.
• Off — Static snapshots, reports, and any data that is updated less than hourly. Visitors see the data as it was when the page loaded; use a manual reload trigger or scheduled server-side cache invalidation instead.