Skip to content
My Beast
Cart
Developer docsMenu

Errors · Getting started

Quickstart

From a new project to your first issue in six steps. You need a Laravel 12 or 13 app on PHP 8.2 or later, and a few minutes.

1. Add Errors to a project

Pick Errors and a package on its page, name your project and pay. The project is the app you send errors from; its environments (development, staging, production to begin with) are set once for every product, on the project's page at id.my-beast.com.

Open the project in Errors. Until Errors first hears your app, its Overview is the setup guide: the same steps as this page, with your project's address and public key filled in.

2. Install the Laravel SDK

In your app's folder:

Terminal
composer require mybeast/errors-laravel
php artisan vendor:publish --tag=mybeast-errors-config

The second line copies the config to config/mybeast-errors.php. From now on every exception Laravel reports is captured, with no code to write; Laravel's dontReport list still applies.

3. Add the keys to .env

.env
MYBEAST_ERRORS_URL=https://services.my-beast.com/errors
MYBEAST_ERRORS_PUBLIC_KEY=pk_…
MYBEAST_ERRORS_SECRET=sk_…
MYBEAST_ERRORS_SIGNING_KEY=sig_…
MYBEAST_ERRORS_WEBHOOK_SECRET=whsec_…
MYBEAST_ERRORS_ENVIRONMENT=production
  • The server secret lets the app send. It is shown once, when it is made in Errors' Settings → Keys.
  • The public and signing keys are for browser errors, the webhook secret for telling customers. The signing key and the webhook secret can be shown again in Settings → Keys.
  • MYBEAST_ERRORS_ENVIRONMENT names where this copy of the app runs: one of the project's environments.

When your project was made at id.my-beast.com, Secrets already holds the address and the four keys, values filled in, in each environment. An app that takes its .env from Secrets has them; only the environment line is yours to add.

Keep the secrets on the server

The server secret, the signing key and the webhook secret never go into a page, a bundle or a repository. Only the public key may reach the browser, and the Laravel SDK hands it over for you.

4. Check that Errors hears the app

On the app's server:

Terminal
php artisan mybeast:errors-test

It prints what is set, checks in with Errors at once and says whether Errors heard the app, or why not. It sends no error, so nobody is alerted. When it works:

Output
URL               https://services.my-beast.com/errors
Server secret     set (MYBEAST_ERRORS_SECRET) - server errors
Public key        set (MYBEAST_ERRORS_PUBLIC_KEY) - browser errors
Signing key       set (MYBEAST_ERRORS_SIGNING_KEY) - who a browser error hit
Environment       production
Errors heard shop (production). Its overview says so under "What arrives".

The setup guide in Errors waits for this check-in and turns into the project's dashboard as soon as it arrives. If the command says something else, Nothing arrives has each answer and its fix.

5. Keep the scheduler running

Errors are sent right after each response and each queued job. Laravel's scheduler sends whatever is left every minute and checks in every hour, so an app with no errors can be told from one that can't reach Errors. Run it as you would for any Laravel app:

crontab
* * * * * cd /path-to-your-app && php artisan schedule:run >> /dev/null 2>&1

Without it, an app with no errors looks silent: an environment heard before and silent for 3 hours is reported once as gone quiet, to the project's people by e-mail unless its Settings → Notices say otherwise. Local, testing and development environments never are.

6. Send a first error

Report an exception by hand, then send it straight away instead of waiting for the next minute:

Terminal
php artisan tinker --execute="report(new RuntimeException('My first error'))"
php artisan mybeast:errors-flush

Open Issues in Errors: My first error is there, with its stack, the source lines around your own frames, and the environment and release it came from. Resolve it once you've had a look.

Next steps