Verify the setup

Run one harmless Scheduler task and confirm that Sentry receives its check-in. This proves that TYPO3, Sentry, the alert API, and the extension configuration work together.

Before you start

Use an integration, staging, or production system whose TYPO3 application context starts with Production.
Choose a task that is safe to execute on demand.
Complete the Configuration first.

Warning

Do not test with a business-critical import, export, or cleanup task unless you understand the effect of running it manually.

1. Find a task UID

List the configured Scheduler tasks:

vendor/bin/typo3 scheduler:list

Record the UID of a harmless task.

2. Run the task

Replace <task-uid> with that UID:

vendor/bin/typo3 scheduler:execute --task=<task-uid>

The command must run with the same Production context and environment variables as the regular Scheduler cron job.

For a local Docker installation whose regular context is Development/docker, enable monitoring for this single command while retaining the Docker database configuration:

TYPO3_CONTEXT=Production/docker vendor/bin/typo3 scheduler:execute --task=<task-uid>

The context must start with Production. Keep the /docker suffix locally; Production/Integration selects integration infrastructure such as its database host and usually cannot run in a local Docker network.

Run the configured task through scheduler:execute. Starting its Symfony command directly bypasses the Scheduler integration and does not create a Sentry monitor.

3. Check Sentry

Open the Sentry project and verify these results:

Location	Expected result
Crons	A monitor named `<normalized task title>-uid-<task UID>` exists.
Monitor details	The latest check-in has the `ok` status for a successful task.
Alerts	An issue alert named ``Monitor Alert for <normalized task title>-uid-<task UID>`` exists.

The first execution creates the monitor and issue alert. Later executions reuse the matching alert rule.

4. Test a failure safely

To verify Microsoft Teams delivery, use a dedicated test task that returns false or throws an exception. Run it only in a controlled environment. The expected result is an error check-in followed by a Teams notification from the generated Sentry alert rule.

The extension does not ship a failing test task. Remove or disable your test task after verification.

If an expected result is missing, use Troubleshooting.