Service unavailable with HTML error page or 500 errors

What to do

• Check whether you use Coveralls Coveralls.io Web, Coveralls.io API. Check your stack

  Paste a package.json, lockfile, Terraform or a list of domains at down.guide/stack to see every provider you depend on.

• Confirm your retries, queues and scheduled jobs caught up after the 11m it lasted.

  Anything that failed between 2025-08-14 14:35 UTC and 2025-08-14 14:45 UTC may need a replay.

• Subscribe to Coveralls's feed to hear about the next one first. RSS feed

  https://down.guide/feed?provider=coveralls works in Slack (/feed subscribe), Discord feed bots and any RSS reader.

Updates from Coveralls 3

1. identifiedAug 14, 2025, 2:35 PM UTC

   The issue has been identified and a fix is being implemented.

   provider

2. resolvedAug 14, 2025, 2:45 PM UTC

   This incident has been resolved.

   provider

3. postmortemAug 14, 2025, 2:47 PM UTC

   A postmortem for this incident and its related incidents has been posted [here](https://status.coveralls.io/incidents/wqbsxnzv0jsf): * [**Postmortem: Reports of “Website under heavy load” errors**](https://status.coveralls.io/incidents/wqbsxnzv0jsf) **Related incidents** 1. **Aug 13**: [Intermittent request rejections](https://status.coveralls.io/incidents/1n7plxrj8j44) 2. **Aug 14**: [Service unavailable with HTML error page or 500 errors](https://status.coveralls.io/incidents/v5mcbrsbhgt4) 3. **Aug 18**: [Reports of "Website under heavy load" errors](https://status.coveralls.io/incidents/fr6sp5kyn128) 4. **Aug 19 \(Today\)**: [Reports of "Website under heavy load" errors](https://status.coveralls.io/incidents/wqbsxnzv0jsf) ‌ **Previous postmortem, prior to final resolution:** We received customer reports early this morning PDT, Thu, Aug 14, indicating that the [Coveralls.io](http://Coveralls.io) service was unavailable for a substantial period overnight. While our Dequeue Graph appears unresponsive since 18:00 UTC yesterday Aug 13 / 11:00 PDT yesterday, Aug 13, this does not seem to be related to the unavailable period, which appears to have started around 02:00 UTC Aug 14 / 22:00 PDT Aug 13, because we were in service all day and afternoon yesterday, Wed, Aug 13, through EOD PDT. Our uptime ping did not catch this because Phusion Passenger was returning an HTML error page. Some customers report receiving a 500 error in that message; others report simply receiving HTML as their API response instead of JSON. While we have not seen production bugs specific to the issue, we suspect it’s because the issue occurred at the Passenger/Nginx layer, which simply prevented new traffic since occurring. As far as previously received coverage report uploads, we see successful background processing of jobs in queue all through the evening into this morning. We suspect as root cause a regression from a deploy around 5pm yesterday, due mainly to the fact that rolling back to a previous deploy has, so far, resolved the issue. We will investigate further to obtain a full understanding of the root cause, but in the meantime, we’ll continue monitoring. Please reach out if you are still experiencing any form of error page in Web requests, or any non-200 API response from C[overalls.io.](http://Coveralls.io) Our apologies for the inconvenience. **Note**: **Recommended** **Best Practice**: `continue-on-error: true` As a general best practice, we recommend adding the **input option** `continue-on-error: true` \(for [Coveralls GitHub Action](https://github.com/marketplace/actions/coveralls-github-action#inputs)\), or `continue_on_error: true` \(for [Coveralls Orb for CircleCI](https://circleci.com/developer/orbs/orb/coveralls/coveralls#commands-upload)\); or the `--no-fail` **flag** \(for [Coveralls Universal Coverage Reporter](https://github.com/coverallsapp/coverage-reporter?tab=readme-ov-file#usage)\), which will keep Coveralls errors from breaking your CI workflows in the future.

   provider

Corrections

None so far.

Something wrong on this page? Report an error or send us a note. Every fix is listed here.