For publishers
The Daybreak bot
You are here because a Daybreak request showed up in your server logs. This page tells you what we fetch, how often, and how to make it stop.
Who is fetching
Daybreak presents two separate identities, because two very different things are going on. They are deliberately distinct so you can allow one and exclude the other.
DaybreakBot/1.0 (+https://daybreakapp.news/bot)
robots.txt token: DaybreakBot
What: Unattended. Polls the curated RSS feeds, and fetches article pages to read their og:image when a feed ships no usable preview image — both when building a briefing and when such a card scrolls into view.
How often: Every 10 minutes per feed, at most 14 article pages per feed per cycle.
Daybreak/1.0 (+https://daybreakapp.news/bot)
robots.txt token: Daybreak
What: Triggered by a person. Fetches the one page someone just opened — for the reader view and its image — or a preview of a feed they added themselves.
How often: One article URL per action — opening the reader can cost up to two requests for it (the text and, if needed, the preview image) — with no retry loop after a failure. This identity is not cryptographically verified, so a request bearing it is not guaranteed to correspond to an actual person's action.
What we do not do
- We do not crawl your site. We fetch your feed and exactly the article URLs it links to — we never follow links found on the page.
- We do not bypass paywalls. When extraction yields only a teaser, Daybreak shows your feed's own summary and links out to you.
- We do not proxy or cache your images. When a feed ships no usable preview, we read the article page's og:image address server-side; the asset itself is then requested from you by the reader's browser.
- We do not hammer after a failure. A failed article page is final for the session, and a 429 pauses the queue. Only the feed poll retries at all — once, and only when an entire refresh came back with no articles whatsoever.
How to make it stop
Email is fastest: write to us and we will remove your source. No justification needed, and we will not argue about it.
You can also work at the HTTP layer: a 403 or 429 served to either identity above is respected and never worked around — we will not switch identity or address to get past it.
Both identities obey your robots.txt, each under its own rules: “User-agent: DaybreakBot” governs only the unattended fetching, “User-agent: Daybreak” the on-demand kind. So you can exclude one and keep the other. We request your robots.txt under the very identity we are reading it for, so blocking one of them still leaves us able to see the rules written for the other. A change takes effect within 10 minutes for any page we have not already fetched — that is the longest we cache your robots.txt. A page already in our cache at that moment can still be served for up to 10 minutes more, because the two caches expire independently, so 20 minutes is the worst case.
What robots.txt does not cover here: fetching the feed itself — neither your RSS file nor the preview someone sees when adding a feed of their own. A feed exists to be fetched, and robots.txt governs the crawling of pages. So “User-agent: Daybreak” keeps us off your article pages, not off your feed; email is the way to stop that.
One limit we would rather state than leave you to discover: if your robots.txt cannot be retrieved at all — a 5xx, a timeout, or a refused connection — the unattended fetching of your article pages pauses, but the person-triggered kind does not. An unreadable file cannot be told apart, from the outside, from one that forbids nothing, and we would rather not disable the reader for every publisher whose server hiccups. An explicit “Disallow” is obeyed either way, and email or a 403 on the page itself achieves the same immediately.