MySQL timestamp > now() - 30s in 2026

If you searched for timestamp > now() - 30s, this page is the MySQL-safe pattern you can ship in 2026. The intent is correct, but the syntax must be explicit: compare against NOW() - INTERVAL 30 SECOND. This avoids parser ambiguity and keeps the query readable when your team revisits incident timelines later.

Most short-window failures happen when systems mix time units or zones. If the table stores native timestamps, compare directly in UTC. If the table stores epoch integers, normalize to one unit before filtering. A 10-digit number usually means seconds; 13 digits usually means milliseconds. That one check prevents a large class of false negatives.

Production-ready MySQL example

SELECT id, created_at, payload
FROM events
WHERE created_at >= NOW() - INTERVAL 30 SECOND
ORDER BY created_at DESC;

Related EpochConverter pages

Need the cross-database version first? Use timestamp now minus 30s guide. For PostgreSQL syntax, check PostgreSQL timestamp now minus 30s. To verify live values before deploying a filter, open current UTC timestamp.

Need fast conversion while debugging SQL output? Open the main epoch converter tool.

Related developer tool

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

Frequently Asked Questions

Is `timestamp > now() - 30s` valid MySQL syntax?

Use `NOW() - INTERVAL 30 SECOND` in MySQL. The shorthand `30s` is not the reliable interval form for production queries.

Should I use UTC in MySQL for this query?

Yes. Store and compare timestamps in UTC, then convert only at the display layer. This prevents offset and daylight-saving drift.

Why do last-30-second filters miss rows?

Common causes are timezone mismatch, comparing strings instead of timestamp columns, and mixing epoch seconds with milliseconds.

Should the comparison be > or >=?

Use >= when you want an inclusive 30-second window. Use > for strict boundaries; keep the choice consistent with retries and metrics.