Don’t store runtime timestamps in Magento configuration
Writing heartbeat timestamps or runtime state into Magento configuration invalidates config cache and causes unnecessary churn. Use flags or a dedicated table instead.
Writing heartbeat timestamps or runtime state into Magento configuration invalidates config cache and causes unnecessary churn. Use flags or a dedicated table instead.
A custom integration saved heartbeat timestamps into Magento configuration. Moving that runtime state into Magento flags stopped needless configuration cache invalidations.
The problem
Some integrations save “last run” timestamps into core_config_data on every run. Each save can trigger config cache invalidation, forcing Magento to rebuild configuration and adding avoidable load.
RELATED GUIDEFlutter vs React Native in 2026: which should you choose? → Need reliable ecommerce support?Patches, upgrades and fixes from certified developers.Get a free store health check →Better options
- Magento flag model for simple runtime values
- A dedicated table for integration state
- Application logs for history
- Monitoring tools for heartbeats
Common mistakes to avoid
How we help with development
Frequently asked questions
How do I know if config cache is churning?
Frequent config cache invalidations in logs or monitoring are a sign.
Is this only a performance issue?
Mostly, but it can also make behaviour harder to predict.
Can you audit custom modules?
Yes — as part of a code audit.