See your first Laravel run.

1. Install and connect

This quickstart targets v1.3.0. A newer v1.4.0 release is available in the release notes; the commands below remain pinned to v1.3.0. The latidoflow/laravel adapter supports Laravel 12 or 13 and PHP ^8.2, subject to your Laravel version's PHP requirements. See the release on Packagist or GitHub.

1. Create your account and verify your email, or sign in to your existing workspace.
2. Open Workspace integration. Under Issue runtime credential, enter a token name and issue the token. Workspace owners and admins can do this.
3. Copy the token before leaving the page. Store it in your application's environment; it is shown only once.

composer require latidoflow/laravel:v1.3.0
php artisan latidoflow:install

# .env
LATIDOFLOW_TOKEN=replace-with-your-runtime-token
LATIDOFLOW_PROJECT_SLUG=default
LATIDOFLOW_ENDPOINT=https://www.latidoflow.com

A new workspace includes a project with the slug default. Use that slug for your first connection, or the slug of the existing project you want to monitor. The adapter uses APP_NAME for its project name and APP_ENV for its environment. The install command publishes config/latidoflow.php while preserving an existing file. Keep the token and cached configuration out of version control.

Choose one path below: Scheduler or queue job.

2A. Connect a scheduled task

In routes/console.php, give your existing scheduled command a unique, stable name. Keep its current frequency and timezone; replace the example command with yours.

use Illuminate\Support\Facades\Schedule;

Schedule::command('reports:daily')
    ->daily()
    ->name('Daily reports');

Use a foreground command() or exec() schedule for this first connection. It must run at intervals of one minute or longer. Unnamed schedules cannot report runs automatically, and sub-minute schedules are unsupported. Add the name to the existing schedule rather than registering it twice.

Continue with synchronization and your first run. Let the existing scheduler execute the command when it is due. Running the command directly bypasses the Scheduler lifecycle.

2B. Connect a queued job

In config/latidoflow.php, add your existing job to queues. Replace the example class, connection and queue with the exact values your application uses.

'queues' => [
    [
        'name' => 'Invoice exports',
        'connection' => 'redis',
        'queue' => 'billing',
        'job_class' => App\Jobs\ExportInvoices::class,
        'runtime_reporting' => true,
    ],
],

The connection is a configured connection name from config/queue.php, such as database or redis. The queue is the actual queue name, often default. Only jobs matching all three values are monitored. Choose one business-critical job for your first connection.

Continue below, reload your workers, then dispatch a new job through its normal application action. A job that was already queued before setup may not carry the monitoring identity.

3. Synchronize and see your first run

php artisan config:clear
php artisan latidoflow:sync --dry-run
php artisan latidoflow:sync

Check that the dry run lists your chosen workload and environment. The sync command creates or updates its heartbeat monitor. php artisan latidoflow:verify performs the same definition synchronization; it does not execute your task.

If your deployment uses cached configuration, rebuild it with php artisan config:cache. Reload long-running application, queue and scheduler processes through your normal deployment procedure so producers and workers all use the new configuration. For Laravel queue workers managed by a process supervisor, use php artisan queue:restart; for Horizon, use php artisan horizon:terminate with its supervisor running.

1. Wait for the scheduled task to run, or trigger a new queued job through its normal application action.
2. Open Heartbeats in LatidoFlow and select the monitor with the name, project and environment you synchronized.
3. Under Diagnostic timeline, find the new run. Check its timestamp, Success status and Duration.

A completed run with status and duration confirms the first connection. You can add business-output checks later to validate what the task produced. Definition synchronization and the Workspace integration milestones alone do not confirm task completion.

If the run does not appear

php artisan latidoflow:doctor --skip-sync

This command checks configuration, definitions, cache, queue and the public monitoring-pipeline health without synchronizing definitions. Fix any reported blockers, then repeat synchronization after a configuration change. php artisan latidoflow:doctor also attempts a definition sync.

• Authentication fails: use the runtime token from Workspace integration in LATIDOFLOW_TOKEN, then refresh configuration and processes.
• Definition missing: check the schedule name or the queue definition in the dry run. Synchronization needs at least one workload.
• Monitor exists but no run: confirm the scheduler executed the named task or a new job matched the class, connection and queue. Confirm producers and workers reloaded the package.
• Run is still in progress: inspect the task and worker in your application and check that the endpoint is reachable from that process.

After the first connection

Run latidoflow:sync when workload definitions change. Configure output checks and alert delivery when you are ready to validate business results and receive notifications. For advanced adapter options, see the v1.3.0 package guide.

Native HTTP remains a complete supported path for applications that do not use the adapter. The Runtime signals guide covers heartbeat and lifecycle requests; the API reference covers definition synchronization.

To roll back an adapter change, restore your previous composer.json and composer.lock, run composer install --no-interaction --prefer-dist, retain your configuration, then rebuild or clear its cache and reload long-running processes. This preserves hosted monitor definitions and history.