TYPO3 monitoring from content element to scheduler
XICTRAQ monitors the frontend, backend login and robots.txt of your TYPO3 website, and the scheduler via a heartbeat, and reports failed pages, missed scheduler runs and a robots.txt that locks out all crawlers. The cookieless tracker measures page views, Web Vitals and JavaScript errors on the pages you embed it in.
Check these paths first
- Uptime monitoringHomepage with keyword check
/ - Uptime monitoringBackend login at the default entry point
/typo3/ - SEO monitoringrobots.txt, e.g. as a static route in the site configuration
/robots.txt - SEO monitoringSitemap index of the seo system extension
/sitemap.xml - Security scanGit directory inside the web root
/.git/HEAD
Why checking the homepage is not enough for TYPO3
A TYPO3 website consists of the core, extensions, a sitepackage with TypoScript and Fluid templates, and the site configuration of each site. Errors therefore do not only show up as a failed page: a single plugin can fail with an error message while the page answers with HTTP 200, and the scheduler can stop without anything showing in the frontend.
XICTRAQ therefore spreads the checks across several modules: uptime monitoring with subpages, keyword check and maintenance detection, heartbeats for the scheduler, SEO monitoring for robots.txt and sitemap, the screenshot changelog for visible changes and the security scan for exposed files and security headers.
The paths on this page follow the TYPO3 defaults: the backend under /typo3/ and the sitemap index of the seo extension under /sitemap.xml. If you have changed the backend entry point or language versions live under their own paths such as /en/, what counts is the address your installation actually uses.
If the backend is shielded by an IP restriction or access protection, /typo3/ also answers XICTRAQ with an error. In that case, leave the path out of the subpages.
What typically breaks on TYPO3 websites
Exception after an update
If page generation aborts with an uncaught exception after a core or extension update, TYPO3 shows the “Oops, an error occurred!” page in production context and usually answers with HTTP 500. Uptime monitoring treats status codes outside 200 to 399 as an outage unless it recognises maintenance or bot protection, and reports configured subpages separately. This also reveals a single failing subpage, such as the one with the search or a form, provided you have configured it.
Plugin fails, page answers with 200
If a plugin or content element throws an exception, TYPO3 in production context replaces only that part of the page with the message “Oops, an error occurred!” plus an identifier and delivers the rest with HTTP 200. According to the TYPO3 documentation, such a page can also end up in the cache. Uptime monitoring does not see an outage here. A keyword check on the monitored URL, if your plan includes it, does report when a word is missing that only this plugin outputs; it does not search for the error message itself.
TYPO3 maintenance mode counts as an outage
With the pageUnavailable_force setting, TYPO3 locks the frontend for all visitors outside devIPmask and answers with HTTP 503. XICTRAQ treats a 503 response as maintenance only if the page title carries a notice such as “Wartungsmodus” or “maintenance mode”, or the text contains “Wartungsarbeiten” or “Wartungsmodus”. The TYPO3 default page carries no such notice, so XICTRAQ reports an outage. Configure your own error page with such a notice for status code 503 in the site configuration, or set up a maintenance window in XICTRAQ in advance if your plan includes maintenance windows.
The scheduler stops running
TYPO3 runs scheduler tasks, such as cleaning up old table records or anonymising IP addresses, automatically only if a cron job or a scheduled task on the server calls scheduler:run regularly. If this entry is missing after a server move or the call aborts, the website stays reachable and the standstill does not show in the frontend. Append a heartbeat call to the cron job: if its ping does not arrive within the expected interval plus grace period, XICTRAQ reports the missed run.
Staging block in robots.txt
TYPO3 can deliver robots.txt per site as a static route from the site configuration. If an entry from the staging environment with Disallow: / is carried over, it locks out search engines without visitors noticing. XICTRAQ reads robots.txt at the domain root, reports a Disallow: / for all crawlers as a critical alert and records changes to the file in the changelog.
Visible change after an upgrade or sitepackage change
An upgrade, changed Fluid templates in the sitepackage or a reworked extension can shift the layout while the status code stays at 200. The screenshot changelog compares captures of the page, stores before, after and difference images in the changelog for a clear deviation and raises an alert for a large change. You can view the history of these images if your plan includes the history of visual changes. If the page height changes considerably or the content is clearly offset vertically, XICTRAQ marks the entry as not directly comparable and raises no alert for it, even if content has changed at the same time.
How XICTRAQ recognises TYPO3
Technology detection reads the HTML and response headers of the monitored page, and the security scan evaluates a few more markers than ongoing monitoring does. Maintenance detection, by contrast, evaluates the response itself, independently of the detected system.
- Ongoing monitoring recognises TYPO3 by paths such as /typo3conf/, /typo3temp/ or /typo3/ in the source, by the identifiers data-typo3-role or t3js-, or by the X-TYPO3-Parsetime response header.
- The security scan additionally reads the generator tag and the identifier typo3-extension in the source, and a reference to typo3.org in the response headers. A Composer installation that serves extension files via /_assets/ and shows none of the other markers may not be recognised as TYPO3 by ongoing monitoring.
- XICTRAQ recognises maintenance by a 503 response with a maintenance notice in the page title or text. A 503 without such a notice and without recognisable bot protection remains an incident, even if TYPO3 sends it via pageUnavailable_force.
- If XICTRAQ detects a different CMS instead of TYPO3, for example after a move, it writes a changelog entry naming the old and the new system. If the new system is not recognised, no such entry is created.
- If an error page such as “Oops, an error occurred!” or bot protection comes back instead of the page, XICTRAQ does not assess the CMS in that run and does not infer a system change from it. Server and CDN details from the response headers still apply.
What the tracker captures in TYPO3
Specifically for TYPO3, the tracker contains a branch for linking signed-in visitors. Everything else it measures as on any other website you embed it in. It sets no cookies and, in standard tracking, stores nothing in browser storage.
Captured by the tracker on its own
- Page views with referrer and UTM parameters, Web Vitals such as LCP, CLS and INP where the browser reports them, and JavaScript errors with message, file and line.
- Scroll depth in steps and time on page.
- Clicks on external links and file downloads, such as PDF files from fileadmin.
- Clicks on elements with the data-xictraq-event attribute, for example set in Fluid templates. Further attributes following the pattern data-xictraq-name are sent as properties.
- Form interactions such as view, focus and submit, including forms of the form extension, if form analytics is switched on for the website and your plan includes it.
Not captured automatically
- Signed-in frontend users by themselves: TYPO3 does not pass the identifier of the signed-in user to scripts, and the tracker does not read the fe_typo_user session cookie. Linking only takes effect once your Fluid template outputs the identifier.
- Whether a form was processed on the server, for example whether the finishers of the form extension sent an email. In the browser, the tracker sees at most the submission.
- Actions in the TYPO3 backend such as editor logins, changes to pages and content, or clearing caches.
- Scheduler runs and other command-line commands. Heartbeats exist for these.
- Cart, checkout and revenue from shop extensions for TYPO3 via a dedicated branch: the tracker has none. Only generic detections apply, such as e-commerce entries in a dataLayer, elements with add-to-cart in the class name and addresses containing “checkout”, “kasse” or “danke”. If your plan includes e-commerce tracking, a page at an address containing “danke” can count as an order completion without an amount, even after a contact form.
Link signed-in visitors with xictraq.identify(customerNumber, { group }); this is recorded if your plan includes visitor identification. Report your own events, such as the confirmation page of a form, with xictraq.event(name, props), and amounts from a shop extension with xictraq.revenue(amount, "EUR", orderNumber), recorded if your plan includes e-commerce tracking.
The right modules for TYPO3
Frequently asked questions
How do I add the XICTRAQ tracker to TYPO3?
Add the script tag with your website ID in the data-site attribute to the head of every page, in TYPO3 for example via page.headerData in the TypoScript of your sitepackage or directly in the Fluid layout. The script loads with defer and sets no cookies. If your installation uses a Content Security Policy for the frontend, it must allow the script and its sending address.
Does TYPO3 maintenance mode trigger an outage alert?
By default, yes. With pageUnavailable_force, TYPO3 answers with HTTP 503 and a default page without a maintenance notice, and XICTRAQ treats a 503 without a maintenance notice and without recognisable bot protection as an incident, because an overloaded server answers the same way. Configure your own page for status code 503 under errorHandling in the site configuration, for example a Fluid template whose title contains “Wartungsmodus” or whose text contains “Wartungsarbeiten”: outage and content alerts then pause, while SSL, domain and blacklist alerts stay armed. Alternatively, set up a maintenance window in XICTRAQ in advance if your plan includes maintenance windows.
How do I monitor the TYPO3 scheduler?
With a heartbeat: in the cron job, call the heartbeat’s ping URL after vendor/bin/typo3 scheduler:run, or after typo3/sysext/core/bin/typo3 scheduler:run in classic installations. If the ping does not arrive within the expected interval plus grace period, XICTRAQ reports the missed run. If you pass the command’s return value as exit_code, XICTRAQ treats a value other than 0 as a failure; scheduler:run returns such a value when a task aborts with an exception. The ping does not show whether a task did the right thing in terms of content.
Does XICTRAQ link signed-in frontend users automatically?
Not by itself. TYPO3 does not pass the identifier of the signed-in user to scripts, and the tracker does not read the fe_typo_user session cookie. If your Fluid template outputs an element with data-fe-user-id or data-felogin-user and the user identifier for signed-in visitors, the tracker links the session to that identifier; the value 0 counts as not signed in. xictraq.identify(), window.xictraqUser, the xictraq:user-id meta tag or a data-user-id attribute carrying an identifier that your Fluid template outputs work as well; the link is recorded if your plan includes visitor identification.
Does the security scan look for TYPO3-specific files?
No, it requests general files such as .git/HEAD, .git/config, .env, backup.sql, dump.sql, phpinfo.php or adminer.php and lists those that answer with HTTP 200. If a server answers every address with 200, the scan only requests the files whose content it can verify. In a Composer installation, the web root points to public by default and project files lie above it; in a classic installation, the project folder itself is the web root. In addition, the scan evaluates security headers, a version number in the Server response header and any X-Powered-By response header.
Which sitemap does XICTRAQ check on a multilingual TYPO3 website?
The sitemap check reads /sitemap.xml at the domain root, resolves a sitemap index and reports addresses from a sample that answer with an error status of 400 or higher; it runs for verified websites if your plan includes it. In TYPO3, each language with its own entry point has its own sitemap, such as /en/sitemap.xml, which the check does not read. The seo extension only serves its sitemap at /sitemap.xml with a route enhancer; since TYPO3 14.1 it comes with the typo3/seo-sitemap site set, previously it had to be added to the site configuration.