---
title: "Tips and best practices"
manual: "Temporal Cache Management"
version: "main"
source: "Backend/Tips.rst"
rendered: "2026-10-07T14:40:31+00:00"
---

# Tips and best practices {#backend-tips}

## Check the database indexes first {#backend-tips-indexes}

The extension ships the indexes it needs in [`ext_tables.sql`](https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ExtensionArchitecture/FileStructure/ExtTablesSql.html#file-extension-ext-tables-sql):
an index led by `starttime` and one led by `endtime`, on `pages` and on `tt_content`.
They are created by the schema migrator, not by the extension itself.

**Create the indexes after installing or updating the extension**

```bash
vendor/bin/typo3 extension:setup
```

**Confirm that they exist**

```bash
vendor/bin/typo3 temporalcache:verify
```

The same check appears in the [Reports module](../Administrator/ReportsModule.html#reports-module).
Without these indexes every temporal lookup falls back to a full table scan.

## Using harmonization effectively {#backend-tips-harmonization}

-   **Align the slots with your editorial rhythm**

    If articles are published at 09:00, 13:00 and 17:00, use exactly those times as slots.
    Timestamps are only moved when they lie within the configured tolerance of a slot, so slots far from your
    actual publishing times harmonize nothing.

-   **Review the shifts before applying them**

    The **Harmonization Suggestion** column in the [content view](Content.html#backend-content) shows the
    shift in minutes per record.
    A large shift moves content visibility noticeably; decide per record whether that is acceptable.

-   **Preview a bulk run on the command line**

    [temporalcache:harmonize --dry-run](../CommandLine/Index.html#cli-harmonize) lists every pending change without writing.
    Run it before harmonizing from the backend, since the backend writes bypass the DataHandler and leave no
    history entry to revert.

-   **Start small**

    Harmonize one table at a time with `--table=pages` or `--table=tt_content`.

## Managing temporal content {#backend-tips-content}

-   **Clean up expired records**

    The **Expired** filter lists everything past its end time.

-   **Watch for clustering**

    The dashboard timeline shows how many transitions fall on the same day.
    Many transitions on one day mean many cache invalidations on that day; that is where harmonization pays
    off.

-   **Export an inventory**

    The backend list has no export.
    Use [temporalcache:list](../CommandLine/Index.html#cli-list) with `--format=csv` or `--format=json`.

## Troubleshooting {#backend-tips-troubleshooting}

### Cache is not updating {#backend-tips-troubleshooting-cache}

1.  Run `vendor/bin/typo3 temporalcache:verify` and fix everything it reports.
1.  Check the timing strategy on the dashboard.
    With the `scheduler` or `hybrid` strategy, confirm that the scheduler task runs — see
    [Scheduler task](../Configuration/Advanced.html#scheduler-setup).
1.  Confirm that the affected record is listed at all, with
    `vendor/bin/typo3 temporalcache:list --upcoming`.

### No harmonization suggestions appear {#backend-tips-troubleshooting-harmonization}

1.  Harmonization must be enabled in the extension configuration — the suggestion column is not rendered
    otherwise.
1.  Check slots and tolerance with `vendor/bin/typo3 temporalcache:verify`, which validates the slot format
    and the tolerance range.
1.  A timestamp outside the tolerance of every slot is left alone by design; widen the tolerance or add slots.

## Access and permissions {#backend-permissions}

The module is registered for administrators only (`'access' => 'admin'`) and is available in the Live
workspace only (`'workspaces' => 'live'`).
Non-administrators do not see it in the **Tools** section.

To hide it from an administrator as well, use TSconfig:

**User TSconfig or Group TSconfig**

```typoscript
options.hideModules := addToList(tools_TemporalCache)
```

Before applying harmonization the module additionally checks write access to every monitored table — by
default `pages` and `tt_content`, plus any table registered through `TemporalMonitorRegistry`.
Administrators pass this check unconditionally.
When the check fails, the request is rejected with a message naming the tables the user cannot modify.

## Next steps {#backend-tips-next-steps}

-   [Configuration](../Configuration/Index.html#configuration) — complete configuration reference
-   [Command-line interface](../CommandLine/Index.html#command-line) — command reference
-   [Performance considerations](../Performance/Index.html#performance-considerations) — performance impact analysis
-   [Dashboard](Dashboard.html#backend-dashboard) — monitor your temporal cache
