I personally arrive to the conclusion after seeing your example images that the main reason why the error pages are accompanied by illustrations is to show that this error belongs to the page itself, since each illustration has the same graphic style than the page to which it belongs. This somewhat reassures the user because:
It's not an error of his/her ...
Your message is probably sufficient, though depending on your brand tone and voice you might consider giving it a little personality.
More importantly, if they can actually DO anything about it - such as clearing their caches, checking their connections, checking uptime status of your services, just waiting five minutes, etc. - tell them what those options ...
The typical 404 Error page that we see these days is a result of the emphasis (and some might even say over-correction) on the user experience of website navigation and interactions.
For those of us that can remember what these pages look like, the default display and content reflected something that was more suitable for the developers that have to ...
The summary on MDN describes 404 Error as;
The server can not find requested resource. In the browser, this means
the URL is not recognized. In an API, this can also mean that the
endpoint is valid but the resource itself does not exist. Servers may
also send this response instead of 403 to hide the existence of a
resource from an unauthorized ...
It does make sense to inform the user since there was already an initial registration process. However, the manner/language to deliver the message should be sorta different from the way a typical error message would be delivered to the user.
Maybe like "Hey there, we couldn't add push notification at this time, please try again".