Bug Management for Laravel
3 min read
You probably came to here because you are a Laravel developer and maybe because you are searching for a bug management solution specific for Laravel.
I have been working professionally fulltime with Laravel for 6 years now and wanted to create a platform that gives me better insights to running applications. I don't believe these utilities should come as a part of an application but rather an external tool that by time can generate its own useful data for further development.
Therefor I used my knowledge and started on a project I call CloudMonitor. As for now I have implemented an outline of what I feel is core essential features for its purpose:
- Bug tracking
All this I have chosen to provide for free. The project is still, as many projects, in development and you have a great opportunity take part in the future as the roadmap is flexible enough for inputs.
This works as any bug tracker you know (Sentry, Bugsnag). You can see a snippet of what is going wrong, a stack trace and query log. Also a collection of events to see how often it occurs and maybe even proactively contact clients to follow up on an issue before they face it too many times with frustrations.
Laravel features scheduled jobs or tasks, which is a very useful tool, however it lacks of good insights and this is what's shown here. Quickly see if the task failed, missing or succeeded but also watch the output in the terminal which is especially useful when it fails to know what failed – it might not always result in an exception.
For now it's build upon Spatie Backup and utilises events from there to track if backups are running and healthy, but also if the cleanup is running.
Checking every 10 minutes to check if the domain is still accessible and if HTTPS that the certificate is still valid.
Everything is done with logs in mind, so you can build statistics on your applications performance and as an extra feature you can add what's called 'Installations', which is collecting data from 2 or more servers running the same software. This is useful if you setup up the same codebase for 2 clients on different servers, but it's not a SaaS, since a bug in one installation would also be a bug in the other and collection of events might be useful across both.