timestamp > now() - 30s in SQL (2026)

If you searched for timestamp > now() - 30s, you are likely building a real-time filter that only returns fresh events. This pattern is used in monitoring systems, status pages, job workers, and live activity feeds where stale rows should be excluded automatically.

In 2026, the safest implementation is to keep server clocks synced, store UTC timestamps, and validate that your incoming epoch values use the same precision as your query logic. Most production mistakes happen when 13-digit milliseconds are compared to 10-digit second assumptions, which silently shifts the time window.

Quick SQL checklist

  • Index your event timestamp column for fast range scans.
  • Store event time in UTC to avoid timezone drift in filters.
  • Standardize one unit for epoch values (seconds or milliseconds).
  • Convert once at ingest rather than at every read query.

Related SQL and epoch pages

Start with the generic guide at timestamp now minus 30s. For engine-specific syntax, use PostgreSQL examples and MySQL examples. If you are validating integer timestamps, check current epoch time.

Need conversion in both directions while debugging values? Open the main epoch converter tool.

Related developer tool

If this query runs on a schedule, validate your cadence with Cron Expression Builder.

Frequently Asked Questions

What does timestamp > now() - 30s do?

It returns rows where a timestamp is newer than 30 seconds ago. This is common for live dashboards, queue monitors, and health checks.

Why can this query return no rows unexpectedly?

The usual causes are timezone mismatch, stale server clock sync, or comparing a timestamp column against a value stored in a different unit.

Should I store epoch seconds or milliseconds for this use case?

Either works if you stay consistent. The key is to document one unit per field and convert explicitly at query boundaries.

How do I keep this query fast in production?

Add an index on the timestamp column, avoid wrapping the column in functions, and keep your filter condition sargable.