A reliable application needs testing during development, checks during deployment, and monitoring after it goes live. GitHub Actions, cron jobs, staging environments, and email each serve a different purpose.
Testing and Monitoring Areas
| Area | What to test or monitor | When to run | Common tool / medium |
|---|---|---|---|
| Local development | Individual functions, input validation, and changed features | Before pushing code | Terminal or IDE; Laravel applications can use php artisan test
|
| GitHub pull request — CI | Unit tests, API tests, database interactions, and code quality | On every pull request | GitHub Actions; results appear as checks on the pull request |
| Deployment pipeline — CD | Required release checks, critical APIs, and application health | Before deployment and immediately afterward | GitHub Actions deployment workflows |
| Scheduled job — cron | Website availability, API health, scheduled task completion, and integrations | At intervals appropriate to each check | Server cron or Laravel Scheduler; failures can trigger email alerts |
| Scheduled GitHub Actions | Longer regression tests and dependency or security scans | Nightly or weekly | Scheduled GitHub Actions workflows |
| Staging environment | Complete user journeys across services, including login and Keycloak SSO | Before a release | Laravel Dusk, Playwright, or Postman/Newman, usually triggered through CI |
| Security monitoring / intrusion detection | Failed SSH logins, suspicious requests, unexpected file changes, and unusual server activity | Continuously, with alerts for suspicious events | Wazuh, Fail2ban, and a web application firewall such as ModSecurity |
| Email notifications | Deliver failed-test reports, downtime alerts, and security notifications | When a relevant failure or event occurs | SMTP or an email notification service, with links to detailed reports |
1. Local Development: Check Changes Before Pushing
Developers should test the feature or bug fix they are working on before sharing the code.
For a Laravel application, run:
php artisan test
Typical checks include:
- Required fields and input validation.
- Function outputs and business rules.
- API responses and permissions.
- Database operations using a separate test database.
Local testing provides quick feedback and helps catch problems early.
2. GitHub CI: Automatically Test Every Pull Request
Continuous integration, or CI, runs automated checks when code is pushed or a pull request is opened.
A GitHub Actions workflow can run the test suite and display the result directly on the pull request. Repository rules can require these checks to pass before merging.
Typical checks include:
- Unit and feature tests.
- API and database integration tests.
- Code formatting and static analysis.
- Dependency vulnerability scans.
Main purpose: Check whether a proposed code change is ready to merge.
3. Deployment Pipeline: Verify the Release
Continuous delivery or deployment, commonly called CD, handles the release process.
Before deployment, the pipeline should confirm that required tests have passed. After deployment, a small smoke test should verify that the application starts and its essential endpoints respond correctly.
Examples include:
- Application health endpoint responds.
- A critical API returns the expected response.
- Required database connectivity works.
- Authentication endpoints are reachable.
A failed check should stop the release or trigger the defined recovery process. Automatic rollback requires explicit configuration.
4. Cron Jobs: Run Scheduled Operational Checks
Cron runs commands on a server according to a schedule. Laravel Scheduler provides an application-level way to define scheduled tasks.
Useful checks include:
- Did the scheduled backup complete?
- Did a queue worker stop processing jobs?
- Is an external integration responding?
- Is disk usage approaching the configured limit?
- Did an expected scheduled task finish successfully?
Choose the interval according to the problem. Availability checks may run frequently, while backup verification may run daily.
An external monitoring service is useful for availability checks because it can report an outage even when the application server itself is unavailable.
5. Scheduled GitHub Actions: Run Longer Checks
Some checks take too long to run on every pull request. These can run in scheduled GitHub Actions workflows.
Examples include:
- A broader regression test suite.
- Dependency vulnerability scans.
- Longer browser tests against staging.
- Compatibility checks.
Scheduled workflows are useful for periodic testing, but their execution time can vary. Avoid depending on them for time-critical outage detection.
6. Staging: Test Complete User Journeys
Staging is a separate environment used to verify an application before production deployment.
For a Laravel microservices platform, a staging test might follow this journey:
- Open the website.
- Sign in through Keycloak.
- Search for a doctor or hospital.
- Open a profile.
- Submit an appointment or enquiry.
- Verify the expected confirmation.
Staging should resemble production closely enough to reveal integration problems. Use dedicated test accounts and test data.
7. Security Monitoring: Detect Possible Hacking Attempts
Security monitoring watches the running server and application for suspicious activity.
Examples include:
- Repeated failed SSH logins.
- Large numbers of failed application logins.
- Requests attempting to access sensitive files.
- Unexpected changes to application or system files.
- Suspicious processes or unusual resource usage.
Different tools address different needs:
| Tool | Main purpose |
|---|---|
| Wazuh | Collect and analyse security events, monitor file integrity, and generate alerts |
| Fail2ban | Temporarily block sources that match configured repeated-failure rules |
| Web application firewall — WAF | Inspect web requests and block requests that match configured attack rules |
| Email notifications | Notify the responsible person about events requiring attention |
A suspicious event does not automatically mean an attacker successfully accessed the server. Alerts require investigation.
Security monitoring complements secure configuration, timely updates, access controls, and backups.
8. Email: Deliver Results and Alerts
Email is a notification channel. The actual tests and monitoring checks run in GitHub Actions, on the server, or in a monitoring service.
A useful alert should contain:
- Application or server name.
- Failed check or suspicious event.
- Date, time, and timezone.
- Severity and relevant error details.
- Link to the workflow, monitoring dashboard, or logs.
Group repeated alerts where possible so that important failures remain visible. Never include passwords, access tokens, or other secrets in notifications.
Recommended Setup for Laravel Microservices
| Stage | Recommended approach |
|---|---|
| During development | Run relevant Laravel tests locally |
| On every pull request | Run automated tests and code checks in GitHub Actions |
| Before release | Test important user journeys on staging |
| After deployment | Run a small production smoke test |
| During normal operation | Monitor availability externally and check scheduled tasks |
| Continuously | Monitor suspicious server and application activity |
| When action is needed | Send an email alert with a report link |
Run tests that create, modify, or delete sample data in an isolated environment. Keep production checks safe and use dedicated test accounts where necessary.
Top comments (0)