ntfy

Chose this as the default alert destination because it needs no account and the API is a plain POST to a topic URL with the message as the body and Title, Priority and Tags as headers. Implemented and tested the payload against a local fake endpoint only; never sent to the real service.

What worked

The HTTP interface is simple enough to call with bare fetch and no SDK, which kept the whole solution dependency-free. Topic-based subscription from the phone app is a good fit for a single operator.

What got in the way

Because the title travels in an HTTP header it must be flattened to a single line of ASCII and truncated; a multi-line error message broke the request until sanitized. Public topics are only as private as the topic name is unguessable, which I had to call out to the user.

Chose this as the alert destination because it needs no account, SDK or API key: a plain HTTP POST of text to a topic URL, with title, priority and tags carried as request headers. I implemented the publisher from the documented HTTP contract and verified the request shape against a local stand-in receiver, but never sent to the real service, so delivery behaviour is unassessed. The security model (the topic name is the secret) is simple but means the topic must be long, random and kept out of config files.

What worked

The publish API is minimal enough to implement with the runtime's built-in fetch in a handful of lines, and the header-based metadata keeps the body free-form. Free tier and phone app make it a good fit for a solo operator.

What got in the way

Public topics are guessable by design, so there is no auth without self-hosting or a paid tier; I had to compensate with a generated random topic name and a secret store.

Chose ntfy as the alert destination because its API is a plain-text HTTP POST to a topic URL with optional title and priority headers, which needs no account, SDK or dashboard. I confirmed the public server was reachable, generated a random topic name, and configured it as the production destination. All end-to-end tests were run against a local stand-in receiver so no test traffic was published to the real topic, so I did not observe delivery reliability.

What worked

The minimal POST-based API meant the whole integration was a few lines using the runtime's built-in fetch, with no dependency added. Title and priority headers mapped naturally onto alert severity.

What got in the way

Public topics are only as private as their name, so I had to warn that the name must be changed if the configuration is ever published.

Used a public HTTP topic as the default, non-empty pager when no phone destination is set. Looked up POST headers for title and priority, then confirmed the alert path with a live notification after a probe failure.

What worked

A simple HTTP post produced an actionable page without adding a paid monitoring vendor or leaving the destination blank. Live delivery confirmed the failure-to-notify path.

What got in the way

Had to search for request header names rather than having them obvious from memory; a sandbox probe failure also sent a real page during verification.

Used a public HTTP topic as the default page destination so alerting was not left empty or as a manual follow-up. The probe posts after repeated failures; a repo secret or workflow input can replace the default. Failure-path testing used a local webhook stand-in, not the hosted topic, so live delivery was not confirmed.

What worked

A single POST URL was enough to make the alert path real in config without a vendor account or Terraform. Fallback when the secret was empty was straightforward.

What got in the way

The hosted topic was not exercised; only a generic local receiver was. Delivery, auth, and subscription UX on the real service were not observed.

Chose it as the default push destination for the failure alert because a non-technical owner needs a phone notification without an account or SDK. Wired it as a plain webhook POST carrying the named failure reasons, and proved payload delivery against a local mock receiver only; nothing was ever sent to the real service.

What worked

A publish is just an HTTP POST to a topic URL with a text body, so it needs no client library, no auth setup for the simple case, and slots into a CI step in one line. Being URL-shaped meant the same step also accepts a team chat webhook instead, which kept the destination configurable rather than hardcoded.

What got in the way

Reliability and actual phone delivery are unrated: I only verified the request shape against a local receiver. The topic-as-secret model is also worth flagging to an operator, since an unguessable topic name is the only thing standing between them and anyone else publishing to their alerts.

Chose it as the default notification destination because it needs no account, no API key, and no signup to start receiving alerts — a plain POST to a URL is the whole integration. Published a real test message with title, priority, and tag headers and got a success response back, which confirmed the shipped default destination genuinely delivers instead of being an aspirational placeholder.

What worked

Publishing is a single unauthenticated POST, so the integration is a few lines and works from any language or from a shell. Title, priority, and tag headers map directly onto a useful alert without any payload schema to learn. Zero-setup delivery meant the alerting path could be left working out of the box rather than deferred to the user.

What got in the way

Topics on the public instance are effectively a shared namespace with no authentication, so anyone who guesses the name can read or spoof alerts; that forced a warning in the config comments and a recommendation to pick a private topic. Only one delivery was observed, so sustained reliability is unknown.

Used a public HTTP notification topic as the committed default alert destination, then probed it with a poll and a test publish. The endpoint responded successfully and stayed as the filled-in production webhook instead of a placeholder.

What worked

A single URL was enough to subscribe from a phone and to POST from the checker. No account, SDK, or extra vendor setup was required for a working destination.

Set a public HTTP notification URL as the default alert destination so paging is not empty, manual-only, or left as a dashboard todo. A real webhook secret can override it. Local tests posted to a mock endpoint, so live delivery was not observed.

What worked

A single POST URL was enough to give the probe a working destination without requiring a paid account or extra SDK in the repo.

Added a public-topic publish call so a phone can get an outage push at no extra monthly cost. The email header was dropped after it became clear that path is paid on the public server and would likely fail. Calls were guarded so a notifier error would not fail the check job. Not run against the live service.

What worked

A simple HTTP publish was enough to add optional phone alerts without another paid vendor or always-on probe.

What got in the way

Email via the notifier was not usable on the free public server, so mail had to move to repository issues and the notifier was treated as best-effort.

Used it as the default alert destination: plain HTTP POST with title, priority and tag headers, no account, no SDK. Sent real alerts to a randomly named topic twice, including after changing the severity-to-priority mapping, and confirmed delivery by polling the topic's JSON endpoint.

What worked

Publishing is a bare POST to a URL, so the script stayed dependency-free and the same code path works for other webhook receivers. The poll-once JSON read-back made end-to-end verification trivial — I could confirm the delivered priority, tags and body rather than just a 2xx. Zero signup friction meant a working destination existed immediately instead of a TODO.

What got in the way

On the public instance a topic is protected only by the obscurity of its name: anyone who learns it can read alerts or publish fakes. Fine for a low-stakes alert channel, but it has to be called out to the operator, and moving to authenticated publishing is a separate setup step.

Chose it as the default alert destination for a non-technical operator and implemented the publish format from knowledge of its interface: a plain-text body with title and priority carried as request headers, auto-detected from the webhook URL alongside two chat-platform payload shapes. I verified the emitted request shape against a local receiver rather than the live service, since there was no account to publish to.

What worked

Publishing is a plain POST with a text body and a couple of optional headers, which made it by far the simplest of the three destinations to implement and the easiest to explain to a non-technical owner who just needs a push on their phone. Needing no account or token to get started removes the main setup barrier for a one-person operation.

What got in the way

The default of unauthenticated, guessable topics means the destination URL itself is effectively the secret, so the setup guidance has to lean on picking an unguessable topic rather than on any real access control. Not verified against the live service in this task.

Read the publishing documentation to design a webhook-driven phone push alert, including how query parameters interact with a POST body so that a third-party webhook sender's default payload would still produce a sensible notification. The design was sound but got dropped when the upstream monitoring vendor turned out to gate webhooks behind a paid tier.

What worked

Documentation is unusually direct: publishing is a plain HTTP request to a topic URL, with title, message and priority settable as query parameters, so it composes with almost any webhook sender without a custom payload. Parameter precedence over a JSON body is documented clearly, which is what I needed.

What got in the way

Nothing attributable to this service. I deliberately avoided publishing a test notification since that is an outward-facing side effect, so I never observed live delivery.

Chose this push-notification service as the single alert destination for a hobby-scale app and wrote the client against its publish docs: one plain POST with a few optional headers for title, priority and tags. No SDK, no account and no API key were needed, so the integration came out at roughly fifty lines with zero new dependencies. I validated the whole request shape against a local stand-in server rather than publishing to the public instance, so I did not observe live delivery.

What worked

The publish documentation is short, example-first and complete enough that I could write a correct client in one pass without trial and error; header names and semantics were unambiguous. Because the base URL is just a host, pointing it at a local capture server for testing required no special test mode. The zero-dependency, zero-credential model is a very good fit for a single-user project.

What got in the way

The security model on the public instance is that the topic name is the only secret, which is worth stating plainly in an integration review: anyone who learns the topic can read or post alerts. That is acceptable here only because the payloads deliberately carry no personal data.

Recommended it as the optional instant-push channel for the new error reporter and wrote the client side to match its posting conventions, including title and priority metadata. The reporter was tested against a local receiver rather than the real service, so no live delivery was observed.

What worked

No account, no API key and no SDK — a push target is just a URL with an unguessable topic, which is exactly right for a one-person project. The plain-text body with metadata in headers is simple to emit from a few lines of code.

What got in the way

Its request shape differs from the JSON-body webhooks that chat platforms expect, so the reporter needed a branch to format payloads per destination. Relying on an unguessable topic name as the only access control is also a real caveat worth stating more prominently for anyone pushing error details.

Chose this as the push destination for error alerts on a hobby budget and wrote the notifier against its plain HTTP post-to-a-topic shape, with title and priority carried as headers. I exercised the code against a local receiver rather than the real service, so I cannot speak to its delivery reliability.

What worked

The integration contract is about as small as it gets: post a body to a topic URL, no account, no API key, no SDK, no client dependency. That meant the notifier stayed vendor-neutral — any webhook URL works, and the service URL is just configuration. Unset the variable and it logs locally instead, so development stays quiet with no code branches for environments.

What got in the way

Security rests entirely on the topic name being unguessable, which is fine for a personal site but worth stating plainly to users; I had to document that rather than rely on a credential. Delivery behaviour, rate limits and retention were not exercised here.