Custom error page with information tokens implementation
First of all I'd consider if hashing is required. Think that:


It's longer to type and impossible to remember.
If user is calling technical support by phone then he will have hard time to spell it out (especially if not native speaker).
It has not any benefit over a simpler short number.
You're computing a MD5 hash (128 bits, 32 bytes) then converting to hex string (64 characters) then removing the first 26. Are you sure you do not introduce collisions in your hash?!


You already have an ID then you might want to simply return that ID (eventually you may add a check-digit to prevent simple mistakes). This will also simplify your code because you do not need an UPDATE to store the calculated hash (check digit may simply be recomputed). Hashing here is (IMO) just overthinking (if you want to obfuscate the ID simply return its hexadecimal value).



You're using long (mapped to bigint). Do you plan to have more than 2^32 errors in your log? 16 Gb just to store the IDs...it's unlikely, don't consider just the number itself but disk space used for each row which has also a very long string).

You're logging stack trace but you're ignoring exception message and exception types which are probably more important than the stack. 

You're logging the exception as-is but think about MethodInvocationException, AggregateException, TypeLoadException (just to mention few) where content of InnerException (or InnerExceptions) is much more important than its wrapper. You have a nice Exception.GetBaseException() to get the root cause of the current exception.

I don't know how you throw your own exceptions but often I use Exception.Data to provide more context and useful details. It may be not your case but don't forget about it.



You hard-coded 404 HTTP status code, why don't you use HttpStatusCode.NotFound?



DatabaseLogger.InsertLog() (fix your calling code because it's DatabaseLog) is a missed opportunity of generalization. I'd not go with complex architectures, factories and abstractions (but a simple IoC container might do well here), the fact that storage is in a database is a detail.

Also class should be sealed (currently you do not have extension points and it's not supposed to be a base class):

sealed Logger {
    public int Write(Exception exception) {
        var timestamp = DateTime.UtcNow;
        var content = TranslateExceptionToText(exception);

        // Code to write to DB storage...
    }

    private static string TranslateExceptionToText(Exception exception)
        =&gt; exception.GetBaseException().ToString();
}


Notes:


TranslateExceptionToText() is pretty naive, better logic should be used.
I moved responsibility to extract useful information from your error handler to the logger class but you may consider to introduce a 3rd class for this when logic is more complex.
Move SQL code to private const string fields, it's easier to find and edit keeping your code cleaner.
Do not use AddWithValue(). It has some, not obvious, drawbacks. It's not always a bad choice but I think it's easier to stop using it than determining each time if its usage is good or not.
Logging may fail and you dot have any error handling! What's your recovery policy in this case?
Strings for SQL code are not (do not use) interpolated strings. Drop $.
Strings for SQL code are not (do not use) verbatim strings. Drop @.




Application_Error might be simplified:

protected void Application_Error(object sender, EventArgs e)
{
    var exception = Server.GetLastException();
    HttpContextException.Current.ClearError();

    if (IsPageNotFoundException(exception))
        RedirectToNotFound();
    else
        RedirectToError(Logger.Default.Write(exception));
}


Implementation of IsPageNotFoundException(), RedirectToNotFound() and RedirectToError() should be clear but let's write IsPageNotFoundException():

private static bool IsPageNotFoundException(Exception exception)
{
    if (exception is HttpException httpException)
        return httpException.GetHttpCode() == (int)HttpStatusCode.NotFound;

    return false;
}