[OutageDeck] Add provider status badge

[koko3tallah]

Summary

• add /outagedeck/status/{provider} for provider-status badges backed by OutageDeck’s documented public JSON API
• map all six API states to readable badge messages and severity-appropriate colors
• support optional Bearer authentication for the hosted service while retaining anonymous self-hosted access
• cache badge responses for 600 seconds to match OutageDeck’s provider refresh cadence
• cover every status mapping, missing providers, invalid responses, configured authentication, and one live provider request

Why

Projects often depend on external developer services such as GitHub, cloud platforms, and AI providers. This badge lets a project expose the current normalized status of one of those dependencies without requiring an API key or scraping a status page.

The route follows the service/noun/parameters convention and defaults to a neutral status label with no logo or link.

Validation

• npm run test:services -- --only=outagedeck — 9 passing, including the live GitHub provider test
• dedicated optional-auth test — passing
• ESLint and Prettier — passing
• upstream lint, docs, integration, service, package, Docker, and Ubuntu main checks — passing

Disclosure: I build OutageDeck, the upstream API used by this badge.

[github-actions]

	Warnings
⚠️	This PR modified the server but none of its tests. That's okay so long as it's refactoring existing code.

	Messages
📖	✨ Thanks for your contribution to Shields, @koko3tallah!
📖	Thanks for contributing to our documentation. We ❤️ our documentarians!

Generated by 🚫 dangerJS against b759a10

[PyvesB]

Hello @koko3tallah 👋🏻

Thanks for the contribution. The API documentation states the following:

Anonymous | 120 requests per IP hourly

With the current number of Shields.io instances running in parallel, that's roughly 1000 badges per hour max that we'll be able to serve. It will probably be more than enough at the beginning, but a few months down the line, we might hit the limit.

Adding auth support to the badge and setting up an account for a service we don't know is potential work that I'm anticipating down the line for the Shields.io team. I'm also seeing that you can only get API keys with higher limits for paid accounts. Is there anything we could do know for the Shields.io case so that we don't hit issues in the future?

[koko3tallah]

Hi @PyvesB - yes, and thanks for flagging this before merge.

I'm Kerolos, founder of OutageDeck. For the hosted Shields.io service, I'd recommend our Pro plan: $49/month for 5,000 authenticated API requests per hour, per key. That's five times the capacity in your estimate without jumping straight to the $199 Business tier.

To avoid another service change later, I'm happy to update this PR now so the request sends an API key when one is available through Shields' normal secret/config mechanism and falls back to anonymous access otherwise. That keeps self-hosted instances working with no setup, while the hosted service can use the paid quota.

If usage eventually approaches 5,000 requests/hour, Business raises it to 20,000/hour, and that limit is raisable on request. The plan comparison is here: https://outagedeck.com/pricing?utm_source=github&utm_medium=pr&utm_campaign=shields_provider_status

If that approach works for you, tell me which secret/config pattern you prefer and I'll make the PR change. We can handle the account and API key privately through hello@outagedeck.com so no credential is ever posted here.

[PyvesB]

Wait, we won't have to pay for the API, will we?

[koko3tallah]

No — Shields.io will not have to pay. Sorry, my previous reply made that sound like a sales pitch. I’ll provide a complimentary service key with a 20,000 requests/hour quota for the hosted Shields integration and keep it active at no charge; self-hosted instances can continue to use anonymous access. I’ve updated this PR to support Shields’ standard optional-secret pattern and set the cache interval to 10 minutes, matching OutageDeck’s refresh cadence. I’ll send the hosted service key privately once you confirm the preferred handoff.

[koko3tallah]

Implemented in 9da2824: optional OUTAGEDECK_API_KEY Bearer authentication, anonymous fallback for self-hosted instances, a 600-second cache, production config/docs, and an auth-header test. Local formatting, lint, the auth test, and all 9 OutageDeck service tests pass. CI is running.

[koko3tallah]

The new CI run has one unrelated Windows-only failure: The server configuration validation should parse dynamicAndEndpointBadgesEnabled environment values as booleans timed out after 2 seconds in core/server/server.spec.js. The Windows job passed 1,555 other core tests; the same full suite passed on Ubuntu, and every OutageDeck-specific check passed. GitHub does not let a fork contributor rerun this protected job. Could a maintainer rerun that single failed job when convenient?

[PyvesB]

I’ll send the hosted service key privately once you confirm the preferred handoff.

Do you happen to have a Keybase account? That's usually how we share credentials securely amongst the maintainer team.

[PyvesB]

The implementation mostly looks good! One small suggestion for one of the tests.

[koko3tallah]

I don’t have a Keybase account yet, but I can set one up if that’s easiest. Should I send the key directly to you there, or is there a Shields team account I should use?

[PyvesB]

We typically have specific Shields.io teams for each set of credentials. I'll create a new team and invite you once I get your handle. :)

[koko3tallah]

Keybase is ready. My handle is koko3tallah. Please invite that account to the Shields.io team and I’ll place the complimentary service key there.

[PyvesB]

Have created a team and added you there. We usually just upload a text file in the team's folder. It will be securily encrypted by Keybase.

[koko3tallah]

Done. I uploaded outagedeck-api-key.txt to the shieldsotgdeck team folder.

I tested that exact key against the production API before the handoff: HTTP 200, business plan, 20,000 requests/hour. The file already uses the OUTAGEDECK_API_KEY=... format expected by this PR.

Thanks again for setting up the private team.

[PyvesB]

Thanks, I've just propagated the API key to our production servers. Will merge this PR, and then deploy it!

[PyvesB]

Things are live :)