"Something went wrong..." pdf.invoicing.co is down, but I'm using snappdf?

The only regular check from a self hosted system to pdf.invoicing.co would be the Version Check.

This a system task which pings pdf.invoicing.co for the latest version

This provides the functionality to advise whether an update is available.

The other item which some people may not be aware of (but is displayed on the initial setup screen) is that there is opt in/out anonymous bug reporting to our sentry servers. You can opt out of this by setting the .env var SENTRY_LARAVEL_DSN to blank

The last opt in/out service we provide is the hosted PDF generation, this can be opted out by changing to snappdf or another service.

1 Like

Thank you for the explanation and quick response! Much appreciated and understood.

I checked my .env file and I don’t even have a SENTRY_LARAVEL_DSN line. If I’m understanding Sentry documentation correctly, this would mean this functionality is already off, correct?

Sentry documentation:

To avoid this, set the DSN value to null to disable sending errors to Sentry.
You can also do this by not defining SENTRY_LARAVEL_DSN in your .env or by defining it as SENTRY_LARAVEL_DSN=null.

no, you need to explicitly set the variable like this

SENTRY_LARAVEL_DSN=

We set the default connection elsewhere config/ninja.php

HI , me again :wink: , before i start a new topic i wanted to double check one thing. i still receive the OP errors but the timestamp of the error is 2 hours behind the real time , when i check the logs its for example 8:15:45 and the real time when i query “date” is 10:15:45 CEST , i know when time is not right that always is a issue, could this be the case ?

Regards

I’ve seen errors like this before with other PHP applications. When I had these problems, my server was set to a different time zone than I physically lived within. I never thought it would be a problem because the job runs at the same time, regardless.

I’ve never done any research to substantiate it, so it’s more anecdotal than anything else. Based on the fact that your logs are at UTC and actual is CEST, you may wish to try updating the time zone on your server. A brief web search suggests that mismatched time between server and actual can cause issues with cron jobs.