Health Checks

The Health Checks resource provides a unified interface for monitoring both default and custom health checks in your application. Out of the box, Laritor includes built-in checks such as scheduler status, database connectivity, cache availability, session storage, file system integrity, and queue worker health. You can also add your own custom checks (e.g., third-party service pings, API endpoint validation) and track them here.

Navigation: Access Health Checks via the sidebar under the “Health Checks” section.

---

1. Health Checks Index Table

The index displays all configured health checks in a paginated table. Each row shows key scheduling and status information, making it easy to see which checks are passing and which need attention.

1.1 Columns

1. Name

   • The identifier for the health check (e.g., Scheduler, Database, Custom: Payment API).

2. Schedule

   • The CRON expression or human-readable interval at which the check runs (e.g., * * * * * for every minute, daily at 02:00).

3. Last Checked At

   • Timestamp when this check most recently executed. If the check has never run, this field may display “—”.

4. Next Check At

   • Predicted timestamp for the upcoming execution based on the configured schedule.

5. Active

   • Indicates whether the health check is currently enabled (ACTIVE) or disabled (INACTIVE). Disabled checks will not run or report status.

6. Status

   • Current outcome of the most recent run:
     • HEALTHY: Last run completed successfully and returned expected output.
     • FAILED: Last run returned an error or unexpected output.

7. View Icon (👁️)

   • Click to open the Health Check Details page for this specific check, where you can review historical runs and outputs.

1.2 Search Filter

Above the table, there is a Search field that matches against the Name column. Enter any part of a health check’s name to filter the list (for example, typing Database will show both the built-in Database check and any custom checks that include “Database” in their name).

Tip: Keep health checks well–named and descriptive to make search filtering more effective (e.g., prefix custom checks with “Custom:”).

---

2. Health Check Details

Clicking the View icon for a health check opens its Details page. This view provides an at-a-glance summary and a full history of past executions, enabling you to troubleshoot any failing checks or verify consistent success.

2.1 Health Check Summary Card

At the top of the Health Check Details page, a summary card displays the same fields shown in the index:

• Name
• Schedule
• Last Checked At
• Next Check At
• Active (ACTIVE or INACTIVE)
• Status (HEALTHY or FAILED)

This summary gives you immediate context on when the check last ran, its next scheduled run, and whether it passed or failed most recently.

Tip: If you need to disable a misbehaving health check temporarily, toggle the Active flag back in your configuration. Disabled checks will not run until reactivated.

2.2 Checks Section: Execution History

Below the summary card, you’ll find the Checks section—a table listing all historical runs for this specific health check. The table provides detailed insight into each run’s outcome and output.

2.2.1 Columns

1. Ran At

   • Timestamp when the health check executed (e.g., 2025-05-30 18:10:00).

2. Status

   • Outcome of that run:
     • COMPLETED: Check returned expected result.
     • FAILED: Check returned an error or unexpected result.

3. Output

   • The raw output or summary from the check (for example, Connection successful, Cache check: OK, or a failure message like Error: Unable to connect to Redis).

4. View Link (if any)

   • For checks that produce extended logs or require deeper investigation, a “View” link may appear—navigating to a dedicated log or diagnostic page. (If no separate view is needed, this column may be omitted or display “—”.)

2.2.2 Ordering & Pagination

• Ordering: Rows are sorted by Ran At in descending order (most recent first).
• Pagination: The table displays 25 rows per page. Click Load More at the bottom to fetch the next 25 historical runs.

---

2.3 Filters

Above the Checks table, use these filters to refine the execution history:

1. Date Range

   • Select Start Date & Time and End Date & Time to show only check runs that occurred within that window.

2. Status Filter

   • Clickable badges for COMPLETED and FAILED. Clicking a badge filters to runs with that outcome, helping you quickly locate failures.

Tip: If a check fails intermittently, use the Date Range filter to isolate runs around known incident windows and diagnose causes.

---

3. Best Practices

• Monitor Default Checks First

  • Built-in checks such as Database Connectivity and Queue Worker are critical indicators of application health. Address any failures in these checks immediately to prevent broader system issues.

• Create Custom Checks for Dependencies

  • For external dependencies (e.g., payment gateways, third-party APIs, microservices), configure custom checks that run HTTP pings or simple queries. Track their status alongside built-in checks to detect external outages.

• Use Descriptive Names

  • Prefix custom check names consistently (for example, Custom: Payment API, Custom: Elasticsearch). This makes searching and filtering easier.

• Review Failed Outputs

  • Whenever a check’s Status is FAILED, inspect the Output field and use the Date Range filter to identify any patterns (such as network flakiness at specific times).

• Correlate with Higher-Level Context

  • If a health check fails repeatedly, correlate its run times with incident timelines—use other Laritor resources (Logs, Exceptions, Requests) to identify root causes.

• Adjust Schedules According to Criticality

  • Configure high-priority checks (e.g., Database, Cache) to run every minute, while lower-priority or resource-intensive checks (e.g., large data integrity checks) can run on longer intervals (hourly or daily).

---

By leveraging the Health Checks index, summary views, and execution history—combined with strategic filtering—you can ensure that both built-in and custom health checks consistently verify the integrity of your application and its dependencies.