> One other thought, I intermittently ran into this whilst testing:
>
> acme-client: https://acme-staging-v02.api.letsencrypt.org/acme/authz/foo/bar: bad HTTP: 503
> acme-client: transfer buffer: [{"type": "urn:ietf:params:acme:error:rateLimited", "detail": "Service busy; retry later."}] (90 bytes)
> acme-client: bad exit: netproc(58848): 1
>
> This was not due to any abuse or explicit rate-limiting; rather, it was
> random, likely overload on their end. It got me thinking acme-client will
> return 1 on any error. However a 503 could be interpreted as "try again
> later". A once-daily cron job to update certificates would simply fail
> due to an overload. If we were able to return more granular error values
> to the caller, a decision could be made to say, retry in a few minutes
> rather than abort (as opposed to a more serious error like a 403).

Then again, if LE is getting hammered with requests, then having all
of the worlds clients come back within minutes is probably not going
to help a lot either.

-- 
May the most significant bit of your life be positive.