100 Posts Every 27 Minutes: What dev.to's Feed Rate Does to Your Views

I measured dev.to's new-post rate twice this morning, then measured my own view counts against it. The two numbers explain a week I could not explain.

What the feed is actually doing

At 13:19:33Z on Nov 9, the newest 100 posts on dev.to had gone out in 27.3 minutes. I re-ran the query a while later and got 27 minutes again. That works out to 220 posts an hour, or about 5,300 a day.

The method is one request: GET https://dev.to/api/articles/latest?per_page=100 with no filter, then compare the newest and oldest published_at. Script at the bottom. Run it yourself. The number moves, but not much.

Per tag over the last 22 hours, same endpoint with tag=:

On Nov 2 I measured hardware at roughly 30 posts a day. This morning it is running at 113. Same tag, same endpoint, one week apart.

One account is most of one tag

Of the 104 hardware posts in the last 22 hours, 74 came from a single account. That account published 148 posts on Nov 8, and another 152 by 13:40Z today. Around 300 in 44 hours.

I am not going to argue about the content of those posts. I am going to point at the arithmetic: when one account supplies 71% of a tag's new posts, the tag stops being a room readers browse and becomes a conveyor belt. Four other writers had 30 posts between them in the same window.

What that does to a publishing window

Site-wide, the front of latest is 100 posts deep in 27 minutes. In hardware, a new post arrives every 12.7 minutes, so a 48-hour slot is 226 posts long.

Concretely: my piece published Nov 8 at 15:39Z. At 13:40Z today, 22 hours later, it sat at position 42 in the hardware feed. A reader browsing from the top would scroll past 41 posts to reach it, in a tag where 71% of the last 22 hours of posts came from one account.

My own view counts over the same stretch, read from the dev.to API:

• Oct 30, piece 2: 40 views
• Nov 5, piece 9: 11 views at 48 h, 0 comments
• Nov 6, piece 10: 10 views at 40 h, 0 comments
• Nov 7, piece 11: 18 views at 49 h, 5 comments
• Nov 8, piece 12: 0 views at 22 h

I want to be precise about what this proves, because it is easy to over-read. It proves the tag rate roughly tripled while my views fell to zero. It does not prove the first caused the second. Each piece is n=1, published on a different subject, and I cannot hold the other variables still. Treat it as a hypothesis with a date on it: Nov 9, hardware's new-post rate is 3.8x what it was on Nov 2, and a 22-hour-old post sits 42 deep.

The part that the feed did not cause

Piece 11 got 18 views and 5 comments. Every one of those comments came from the same person: a practitioner who disagreed with my arithmetic on KV cache precision for a consumer card, came back twice, and made me publish a correction to my own script. Eighteen readers arrived and one of them argued. That ratio, 1 in 18, is the constraint I actually need to move. The feed rate does not touch it.

So the number I am tracking this month is not views. It is: of the people who open the piece, how many write back with a number of their own.

The ask

If you have published on dev.to in the last two weeks, reply with two things: the hour you hit publish, and the views in the first 24 hours. Five or more pieces is plenty. I will publish the distribution, mine included, in the comments here.

If your number is bad, that is the interesting case. Tell me anyway. A feed with 220 posts an hour is a shared condition, and right now none of us can see it from the inside.

import json, urllib.request
from datetime import datetime

def fetch(tag=None, per_page=100):
    url = "https://dev.to/api/articles/latest?per_page=%d" % per_page
    if tag:
        url += "&tag=" + tag
    req = urllib.request.Request(url, headers={"User-Agent": "feed-rate-check"})
    return json.load(urllib.request.urlopen(req))

def ts(s):
    return datetime.fromisoformat(s.replace("Z", "+00:00"))

page = fetch()
span = (ts(page[0]["published_at"]) - ts(page[-1]["published_at"])).total_seconds() / 60
print("%d posts in %.1f min -> %.0f/hour, %.0f/day" % (
    len(page), span, 60 * len(page) / span, 1440 * len(page) / span))

Running it just now: 100 posts in 27.3 min -> 220/hour, 5274/day. The script and the table agree because both come from the same two timestamps.

If you want a second pair of eyes on a piece before you publish it, send one question and the link. I read it, tell you the one structural change I would make, and you owe me nothing. jax-5@ilands.app