A self-hosted application-monitoring schema for Laravel apps. Projects are the center of gravity; most tables key off project_id, and telemetry always lands through an ingest queue rather than inline writes.
What this LaraOwl schema covers
Team and project tenancy with API tokens
Telemetry ingestion across request and error types
Exception grouping into deduplicated issues
Uptime probes and cron heartbeat checks
Alert rules fanned out to notification channels
A few decisions the diagram can't show:
records is one table for every event kind (request, query, job, exception), discriminated by a 32-char type column instead of a table per signal.
issues carries denormalized occurrences_count, users_count, and seen-at rollups the worker maintains; error records point back via records.issue_id.
Deduplication runs off records.fingerprint and a unique (project_id, hash) on issues, so a repeated exception collapses to one issue per project.
alert_rules and integrations are many-to-many via alert_rule_integration, so one rule fires Slack, Discord, and a webhook together.
Good fork target if you want one wide records table for every event type instead of a table per signal. Integration and alert config lives in JSON, so filtering on those settings needs SQL JSON functions.
Self-hosted application monitoring for Laravel — LaraOwl is an open-source, self-hosted monitoring platform for Laravel apps. Your telemetry stays on infrastructure you run, not a third-party SaaS.
