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. 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/PDF, role-based column visibility, and auto-refresh. Every table embeds on any page with a [tablecrafter] shortcode or the native Gutenberg block. TablePress has over 800,000 active installs on WordPress.org (WordPress.org, 2026).

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:

The shortcode accepts all column and filter settings defined in the table builder as defaults, but you can override individual parameters inline. For example, `[tablecrafter id="1" per_page="25"]` overrides the default rows-per-page setting for this specific embed without changing the saved table configuration. This lets you reuse one table definition across multiple pages with different display requirements.

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.

This configuration interacts with any caching or CDN layer active on your WordPress installation. If you use WP Rocket, LiteSpeed Cache, or a CDN such as Cloudflare, flush the page cache after making this change to ensure the updated configuration is reflected in the cached HTML served to visitors. TableCrafter's server-side output is regenerated on the next uncached request.

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.

After completing this step, verify the result by viewing the page as a logged-out visitor in an incognito window. This confirms the table behaves correctly for public visitors rather than reflecting admin-level permissions that may hide configuration issues during initial setup. Check both the rendered output and the browser console for any JavaScript errors.

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?

Auto-refresh settings configured in the table builder apply automatically when the shortcode is placed on a page — no extra shortcode attribute is needed to enable it once it is turned on at the table level. You cannot override the refresh interval from the shortcode; the interval is a table-level setting only and must be changed in the table builder admin. If you need the same data displayed with different refresh intervals on different pages, create separate table configurations pointing at the same data source and set each configuration's refresh interval independently.

The one shortcode attribute that does affect auto-refresh is refresh="false", which disables it per-embed regardless of the table-level setting. There is no refresh="30"-style shortcode override — the interval is always sourced from the table configuration, not the shortcode.

How Do I Disable Auto-Refresh for Specific Embeds?

If you have configured auto-refresh in the table builder but want to disable it for one specific shortcode instance — for example on a print-friendly version of the page, an email-accessible summary view, or a page where the polling requests would interfere with a slow server — use:

[tablecrafter id="5" refresh="false"]

This shortcode parameter overrides the table-level auto-refresh setting for that embed only. The table on that page will still load the current data on page load, it just will not poll for updates after load. Other pages using the same id="5" shortcode without the refresh="false" override will continue to auto-refresh at the interval configured in the table builder. This is the only way to disable refresh per-embed without creating a separate table configuration.

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.