http://crt.sh/ (the homepage) seems to alternate between 502 and 404 errors. Is anyone else getting this?
Cheers
Yes, these are exceedingly, and sadly, common.
For some other CT log viewers see: Certificate Transparency Search Resources
Note crt.sh is not run by Let's Encrypt or the ISRG
I moved your post to the Help section as the Site Feedback is for Let's Encrypt.
Here's their post from May saying that they're continuing to work on it. I haven't seen any concrete timeline or real update since then.
As I said somewhere around here a little bit ago, probably the default help template on this forum shouldn't reference crt.sh since it's down so much it's causing more confusion than it's helping.
You probably already know this but incase you dont, you can always connect to their "open to anyone postgres db", for ex via:
psql -t -h crt.sh -p 5432 -U guest certwatch
then you can do a basic (to as complex as you want) query via something like:
certwatch=> SELECT
x509_commonName(c.CERTIFICATE) AS domain_name,
x509_notAfter(c.CERTIFICATE) AS valid_until
FROM
certificate c
WHERE
plainto_tsquery('domaintolookup.com') @@ identities(c.CERTIFICATE)
GROUP BY
domain_name, valid_until
ORDER BY
valid_until DESC;
The postgres db drops a lot too, but you can just instantly reconnect.
Thanks @entropy! After reading the post (in @petercooperjr 's message above), I feel like connecting to their database right now will only make things worse for everyone..! 
I'll look for other solutions for now. Out of pure pure curiosity, do folks here use crt.sh to mostly search / confirm the presence of certificates, or to fetch the whole certificates, etc.? I don't have 60TB of free space to try to duplicate what crt.sh does - but just curious if a subset of their service could have some value (and is runnable on a less-than-60TB kind of setup)
Cheers
Lately if I'm trying to look up a certificate's history (primarily to try to help someone on here), I just use Hurricane Electric's service. But, uh, yeah, trying to have an index to store and search through all certificates ever issued is not for the fainthearted, and not something I'd try to personally do.
I rarely try using crt.sh given its availability. But, when I do searching it is for looking at history when providing help in this community. I don't need it for my own certs / servers.
So when I do search I more recently use CertObserver (CT search here) for quick checks. For more in-depth I have an account at censys.io. Censys allows a small number of requests / day for free without an account and a few more with one. But, the UI is more complex than these others.
If you're looking for a cert monitoring service see: Monitoring Service Options - Let's Encrypt
Almost no one is going to run a fully searchable CT server that you can run searches against (and going back past 2024), even using Googles Trillian setup is a major undertaking (and can be done much simpler). As you mentioned needing ~60TB+, which you can easily cut down to about ~12-14 (possibly less) if you only need 5-8 of the fields, is the least of your issues. Without getting into the current vs Sunlight servers youre looking at month(s)+ of learning and coding if starting from scratch. Although if you dont need the most up-to-date certs there are torrents (geomys/ct-archive github) where you can download each zip that make up the torrent in 10Gish pieces, scrape that and load into your db, delete, get the next and repeat - but even that is not easy. We run a private CT server as we have a need for it (pentesting) but not many other people will ever have a need to run their own.
The database that powers CertObserver's CT search is currently around 630 GB on disk. However, keeping it to that size has required several limitations compared to crt.sh. For example:
- Expired certificates are removed after one month
- Full certificates are not stored
- Pre-certificates and final certificates are deduplicated into a single entry
- Only the earliest logged time is stored
- It's only possible to search by domain/subdomain
P.S. I'm interested in any feedback anyone might have about CertObserver's CT search. For example, things you don't like about it, ideas for how to make it better, or missing features you need.
Expired certificates are removed after one month - I'll tell you why pentesters wouldnt use that - we use it for pentesting so my ideas on it might not be very valuable or what youre looking for at all. For example were contracted to do an external/internal on companyx.com. We get their domain name, we agree on a rules of engagement that defines what we can and cant do (basic stuff, no 0days as theres no fix, no DoS as the last thing you want to do is harm the company in any way - you never even want the client to know youre there, etc), then we get the external and internal IP's, sign the contract that has the scope and we start. We can brute the subdomains via DNS which will always take up resources other then ours, or we can do CT lookups. Anything a company would have wanted to protect or had a password somewhere for they'll most likely have a cert for that. Before LE when a lot more people were running their own CA we always had to DNS brute - that takes forever, it can switch NS's over to one that has a wildcard for the domain so youre not looking for a couple hours and then have 50k useless subdomains that never existed, you can get rate limited and blocked no matter how many NS's you run for onbvious reasons, etc - it was a pita. So the reason pentesters wouldnt use it is because they want the oldest domains, the forgotten about domains with expired certs etc I dont know what your target clients are - but fromthat example Im sure you can see why pentesters wouldnt use it, from the expired domains removed after a month alone. I think youd be surprised how many pentesters use CT for multiple thins. With the good, os pseudo-good, or greyhat-while-your-at-work-hacking-a-contracted-client 
always is going to come the bad. The tool can be used either way depends whos using it. Thats why we chose to run our own - but getting yours down to 630Gb is crazy, ours is 4.9TB and we thought we had the smallest there was. The expired certs are probably whats keeping yours so small though, we wrote ours from scratch (borrowing good ideas where we could find them) in go, we spawn a go fetcher per log (that do checkpointing), those get parsed to strip out everything but domains, issuer, issued_at, expires_at, and the log_id (besides checkpoint every 10kish we keep the index and headindex) those get sent to rabbitmq, another pareser then pulls from rabbitmqs queue and does a bit mroe formatting, then we use clickhouse for the db. Additionally we have a couple go processes spawned that watch whats going into the db and will report to any of our clients if they see anything similar - so they can stop a phish before it even happens (as long as were moderatly current). Its been working really well. I really strayed OT - but if you wouldnt mind sharing the gist of your arch that would be cool Did you go big w trillian, or something like ours?