### Example Usage of FeatureFlagRecorder Source: https://laritor.com/docs/guides/feature-flags This example demonstrates how to wrap a feature flag check with the Laritor recorder to track both active and inactive states. ```php if (feature_enabled('new-ui')) { \BinaryBuilds\LaritorClient\Recorders\FeatureFlagRecorder::recordFeatureCheck( 'new-ui', true ); } else { \BinaryBuilds\LaritorClient\Recorders\FeatureFlagRecorder::recordFeatureCheck( 'new-ui', false );} ``` -------------------------------- ### Install Laritor via Composer Source: https://laritor.com/docs/installation Run this command to add the Laritor client package to your Laravel project. ```bash composer require binarybuilds/laritor-client ``` -------------------------------- ### Send custom logs with LaritorClient Source: https://laritor.com/docs/guides/capture-custom-logs This example demonstrates how to define an array of custom log entries and batch them to Laritor using the addCustomLog and sendEvents methods. ```php use Carbon\Carbon;use BinaryBuilds\LaritorClient\Laritor; $logs = [ [ 'level' => 'INFO', // DEBUG, NOTICE, INFO, WARNING, ERROR, ALERT, CRITICAL, EMERGENCY 'message' => 'custom log 1', 'type' => 'custom-logs', 'written_at' => Carbon::parse('2025-10-24 12:55:55'), 'context' => [ 'user_id' => 1, 'account_id' => 2, 'source' => 'db-audit', ], ], [ 'level' => 'WARNING', 'message' => 'custom log 2', 'type' => 'custom-logs', 'written_at' => Carbon::parse('2025-10-24 12:55:55'), 'context' => [ 'user_id' => 1, 'account_id' => 2, 'source' => 'activity', ], ],]; $laritor = new Laritor(); foreach ($logs as $log) { $laritor->addCustomLog( $log['type'], $log['level'], $log['message'], $log['context'], $log['written_at'] );} // Sends everything added above in a single batch request.$laritor->sendEvents(); ``` -------------------------------- ### Combining refresh and timeline parameters Source: https://laritor.com/docs/guides/live-dashboards Combine `refresh` and `timeline` query parameters for a live operations view. This example refreshes every 30 seconds and opens the dashboard in the 1 hour view. ```url https://your-laritor-dashboard-url?refresh=30&timeline=1h ``` -------------------------------- ### Example Webhook Payload Source: https://laritor.com/docs/integrations/webhooks Example JSON payload sent by Laritor to a webhook endpoint when an alert is triggered. It includes base fields such as application, environment, exception details, and occurrence metadata, plus request-specific fields like URL, headers, and user information. ```json { "application_id": "1", "application": "Weather API", "environment_id": "1", "environment": "production", "exception": "Call to undefined function App\\Services\\foo()", "exception_class": "Error", "exception_id": "1", "file": "/var/www/app/Services/ReportService.php", "line": 78, "first_occurred_at": "2026-03-31T10:00:00Z", "last_occurred_at": "2026-03-31T10:05:00Z", "total_occurrences": 54, "code": "return foo($payload);", "occurrence_type": "request", "exception_url": "https://app.laritor.com/applications/1/environments/1/exceptions/1", "occurrence_url": "https://app.laritor.com/applications/1/environments/1/requests/15", "url": "https://api.example.com/reports/daily", "request_headers": { "accept": "application/json", "content-type": "application/json" }, "request_body": { "report_id": 42 }, "user_id": "15", "user_name": "Taylor Smith", "user_agent": "Mozilla/5.0", "user_ip": "203.0.113.10"} ``` -------------------------------- ### Collect Server Metrics Source: https://laritor.com/docs/installation Schedule this command to run every minute via Laravel Scheduler or system cron to monitor CPU, memory, and disk usage. ```bash php artisan laritor:send-metrics ``` -------------------------------- ### Marking checkout milestones with Laritor::addCustomEvent Source: https://laritor.com/docs/guides/custom-events Use this to track checkout progress, such as when a checkout starts or when payment is authorized, to identify latency and conversion bottlenecks. ```php use BinaryBuilds\LaritorClient\Laritor; Laritor::addCustomEvent('checkout.started', [ 'cart_id' => $cart->id, 'user_id' => $user->id, 'items_count' => $cart->items()->count(),]); Laritor::addCustomEvent('checkout.payment_authorized', [ 'cart_id' => $cart->id, 'payment_provider' => 'stripe', 'amount' => $cart->total(),]); ``` -------------------------------- ### Generate filter class (full observability) Source: https://laritor.com/docs/customization Run this Artisan command to generate a filter class that records all events by default. Useful if you want to record all events initially and override in the future. ```bash php artisan make:laritor-filter ``` -------------------------------- ### Create queue health check with artisan command Source: https://laritor.com/docs/custom-health-checks Run this command to generate a new queue health check file in app/Laritor/. ```bash php artisan make:laritor-queue-hc HighPriorityQueueHealthCheck ``` -------------------------------- ### Configure Laritor Environment Variables Source: https://laritor.com/docs/installation Add these variables to your .env file. Replace your-ingest-url and your-backend-key with the values from your Laritor dashboard. ```text LARITOR_ENABLED=trueLARITOR_INGEST_ENDPOINT=your-ingest-urlLARITOR_BACKEND_KEY=your-backend-key ``` -------------------------------- ### Enable command output recording with SendOutputToLaritor trait Source: https://laritor.com/docs/guides/command-output Add the SendOutputToLaritor trait to a console command class to record its output. Laritor captures info, warn, error, comment, table, and other console messages as part of the command event data. ```php info('Starting import...'); // Import logic here $this->info('Import complete!'); }} ``` -------------------------------- ### Configure Laritor MCP in Cursor Source: https://laritor.com/docs/integrations/mcp-server Configuration for Cursor's .cursor/mcp.json. Use the NYC URL for US accounts and the Amsterdam URL for EU accounts. After adding, create .cursor/rules/laritor-debugging.mdc with alwaysApply: true frontmatter and paste the Laritor debugging policy. ```json { "mcpServers": { "laritor": { "command": "npx", "args": ["-y", "mcp-remote", "https://nyc.laritor.com/mcp"] } }} ``` ```json { "mcpServers": { "laritor": { "command": "npx", "args": ["-y", "mcp-remote", "https://ams.laritor.com/mcp"] } }} ``` -------------------------------- ### Add and authenticate Laritor MCP in OpenCode Source: https://laritor.com/docs/integrations/mcp-server Commands for OpenCode. First run 'opencode mcp add', select 'remote' when prompted, and enter the server URL for your account region (NYC or Amsterdam). Then authenticate the server with 'opencode mcp auth laritor'. After adding, add the Laritor debugging policy to AGENTS.md. ```text US (NYC): https://nyc.laritor.com/mcpEU (Amsterdam): https://ams.laritor.com/mcp ``` ```bash opencode mcp auth laritor ``` -------------------------------- ### Laritor debugging policy instruction for AI agents Source: https://laritor.com/docs/integrations/mcp-server Add this Markdown to your AI agent's instruction file to enforce early consultation of Laritor production telemetry when debugging runtime issues. It defines the required workflow: read `.laritor.json`, search exceptions, inspect the execution timeline, and correlate with local source before fixing. Skip Laritor only when the user explicitly opts out or the task does not involve runtime behavior. ```markdown ## Laritor debugging policy This repository is connected to Laritor through MCP. Whenever the user asks to debug, diagnose, investigate, or fix any of the following: - exceptions- bugs- runtime errors- HTTP 500 errors- crashes- failed requests- unexpected application behavior- production issues you MUST consult Laritor early in the investigation, even if the user does not explicitly mention Laritor. Required workflow: 1. Read `.laritor.json` to determine the Laritor application mapped to this repository.2. Call the Laritor exception search tool for recent relevant exceptions.3. If a relevant exception exists, retrieve its detailed occurrence information.4. Carefully inspect the Laritor execution timeline, including queries, logs, cache operations, outbound requests, jobs, mails, notifications, and other recorded events.5. Treat the ordered event timeline as primary debugging evidence because it shows what the application executed before and during the failure.6. Correlate Laritor production evidence with the local source code before proposing or implementing a fix.7. Do not rely solely on local logs, git history, source inspection, or tests when Laritor production telemetry is available. Do not wait for the user to say "use Laritor". Skip Laritor only when: - the user explicitly asks you not to use Laritor, or - the task cannot involve application runtime behavior, such as formatting code, renaming a variable, or editing documentation. ```