You need to be more specific as to what you are expecting to refresh. For example there are both lazy (triggered after the ttl expiration and not invalidating) and proactive options for refreshing internal materialized views.
I need to refresh my view after TTL has expired. My VDB does not take 2.5minutes to load initially. But the refresh gets delayed by 4 hours.
I think that Steven above referred to this: Teiid has both "lazy" and "proactive" materialized views. Both use the same TTL you specify, but the "lazy" will not refresh itself but it will only when someone uses it after the TTL has expired. So that first refresh after TTL could be slow, but until next TTL all other view usage will be fast.
On the other hand, the "proactive" materialized views will refresh them self anyway, even if noone uses them, and whenever you need the view, it will always be fast.
There are also another distinctions, such as if the mat view should refresh at VDB loading, or at first usage, or to make mat views refresh "underground", while you are using last cached copy, and they get swapped only when the latest refresh is "ready", so users always use fast queries against the mat view. If I remember correctly, this is referred as "invalidation", so look for that term in the docs, around here: Internal Materialization · Teiid Documentation , along many other options and infos... and of course here too: VDB Definition · Teiid Documentation
The docs aren't full of complete examples, though...
I suggest to experiment with unimportant, small mat views, and setting shorter TTL, so it gets easier to understand if the setup is lie you expect, and only when you're satisfied, set the real, longer TTL. And the server.log file is your friend, there you will find details about materialization jobs, when they happen or fail, with many details...