TLDR - I finished a small project that I am sharing for my friends on DEV, that allows you to put your followers count on your Github!
...
For further actions, you may consider blocking this person and/or reporting abuse
ooo very nice.
I know right. 😜 but whats cool is now that I have a github action confidently working, I feel well suited to try other sorts of workflows with github actions. I think thats the real win here! Thanks Francis! ✨️
Yeah, cool alright. But I hope you don't run out of GitHub action minutes before the end of the month! 😄
I'd run this cron once a week max 😊
True. It's probably excessive, thanks for pointing that out! Haha. I don't have enough github actions to notice, but thanks for letting me know that is a thing!!! I would have definitely hit that wall at some unfortunate point. 😅
Ah, we keep learning new things 🥰
That said, your profile repo is a public repo, which means GitHub may not deduct any minute at all, LOL.
But they must have an internal limit, otherwise people will go wild with these ☺️
I can see why now. "Evil laugh" 😂😅🤔🤣
This is a fun use of the API. I went down a bit of a rabbit hole with the followers endpoint this week and discovered something that might make the number itself even more interesting.
I pulled all of my follower data going back to 2017 and found that my account supposedly gained roughly 18,000 followers during 2026, while my posts received only about 14,300 total views. The follower acquisition rate also barely changed based on whether I published anything, and a surprisingly large percentage of the usernames had auto-generated-looking numeric or hex tails.
I can't prove those accounts are bots or generated accounts, so I wouldn't make that claim. But it did make me much more skeptical about treating the raw follower count as an audience/readership metric.
Your GitHub Action actually creates an interesting opportunity, though: since you're already running it periodically, you could save the follower IDs with each run rather than only the count. Over time, you'd get something the DEV dashboard doesn't really give you: actual follower additions and churn between snapshots.
I wrote up my API spelunking here if you're curious.
you can try this approach regarding bots/not bots dev.to/olgabraginskaya/whos-really...
I think I've seen your post before! Thanks for the reminder!!!
Yes! I actually started reading that article! I didnt have time to finish but it was definitely interesting!!!
It's so cool! I customized it a little for my GitHub profile. Thank you! 😸
that's so cooooool!!✨
Niiiiiiiiice. Love it!
Nice one
Thanks! ✨️
Nice works like a charm
Thanksss
Aww!!!! 💜
niceee
Modified it a bit :) Thanks!
Check the code to get the badge here
turazashvili (Nikoloz Turazashvili) · GitHub
#Python #Blockchain #Web3 . turazashvili has 45 repositories available. Follow their code on GitHub.
Nice, looks like it belongs there! Glad you found it of use! ✨️
hehe, yes. thanks again :)
Very well done !
I just upset that I didn't think if this myself 😁
Aww haha. Maybe, make it somehow better? 🤔
I can try 😉
it's good. but I've never understood why dev.to doesn't display followers...
I wondered that as well. Honestly, it doesn't bother me anymore. I think it actually adds quality by not making it some agenda based numbers game. Although we all like to feel validated! I get that. 🤔😅
thx!
343 failed runs before the first success — that's commitment most people wouldn't bother with for a followers badge. The
git diff --quietcheck before committing is a nice touch, saves you from a commit history full of no-op runs. I'd add a failure notification step too though, so if the API key expires or the script breaks, you find out from a Slack ping instead of rediscovering it a year later.🤣🤣🤣 thank you @onizuka
So cool 😍
Hello @hadil , glad you like it! ✨️
I like that this ended up being more than just a follower counter. The interesting part is the workflow: fetch external data, transform it, update a specific section of the README, and only create a commit when the value actually changed. The marker approach is especially practical. It makes the README the presentation layer while keeping the generated part clearly separated from the rest of the profile.
I also noticed some of the discussion around GitHub Actions minutes. For a public repository using standard GitHub-hosted runners, Actions usage is currently free, so the daily schedule isn't necessarily a problem in that case. It becomes more relevant for private repositories and their included quotas.
The bigger takeaway for me is the automation pattern. Once you have this working reliably, the same setup could update other profile data too, as long as the source and update frequency actually justify it. That's probably more valuable than the follower number itself.
Yes, exactly what I was thinking! I want to find other cool ways to use github actions now that I have a grasp of it. ✨️
Haha nice! If I ever start being less lazy and clean up my GitHub README, I'll definitely use it!
💖 awesome! Glad to hear you might find it useful. And yeah... when I added this I had to do some light housekeeping as well. 😅 Profile was getting out of date. Haha.
This is actually a pretty neat use of GitHub Actions. I like that you shared the complete workflow instead of just showing the final result.
The
git diff --quietcheck is a nice little detail too. I might actually use this for my own profile. 😄BTW, you forgot to mention that we also need your
update_script.jsin our profile repo, not just theYAMLfile! 🥰Bam. Done. Just for you. haha 😂
Hahaha yes you are 100% right. I am guilty. 😂🤷♀️
The marker-block pattern here is the underrated part. Separating the generated segment from hand-written content with start and end tags, then only committing when the value actually changed, is the same pattern I use for agent-written files. It keeps the generated stuff auditable: you can always diff exactly what automation touched and nothing else.
The comments discussing follower quality are worth reading too. Any metric you automate onto a profile invites both pride and gaming, so snapshotting the count over time, like Ken suggested with follower IDs per run, gives you the trend instead of a single flattering number. A badge that moves is more honest than one that spikes.
Nice writeup of the debugging journey as well. The permissions block and the auto-push step are the two details most tutorials skip, and they are exactly why most first attempts of this workflow silently fail.
Yes haha, I am living proof of many failed first attempts. Once you know, you know!! 😅🤣. And yes, I like the idea of snapshots over time. Very insightful.
Failed first attempts are how the marker-block pattern gets discovered in the first place 😄 Snapshots over time would make a fun little growth chart for the profile too. Thanks, fun project!
This is such a fun little project! 😄 I love how a tiny side project turned into a useful GitHub Actions workflow, especially with the automatic README update and scheduled runs. The detailed script is also really helpful for anyone who wants to adapt it for their own profile.
I’ve been exploring similar developer tools and projects through CodeCan.net, and this is exactly the kind of practical automation project that makes me want to experiment with GitHub Actions more. Great job getting it back from a year of failed runs! 😂
Thank you Leonore! I feel that having a working version of one process can be used to understand how other related processes might work, and that has real value. I'm glad I was able to spark your interest!
Dope, thanks!
Your welcome!
This is such a fun example of how a “small silly side project” can turn into something genuinely useful. 😄
I especially liked the part about those failed GitHub Action emails slowly becoming the motivation to finally fix the project 😂. Sometimes finishing something we abandoned months ago feels more satisfying than starting something new.
Also, sharing the actual workflow and update_script.js makes this much more useful for others who want to try it themselves. Great little project, and a nice reminder that side projects don’t always have to be serious to be worth building.
Yeah its so wild that some of the most useful learning comes from unexpected places. 😂🦄
Haha I feel this so much! We have a few GitHub Actions at The Printing World that kept failing on us, and I was about ready to throw my laptop out the window. Props to you for actually fixing it instead of just hitting delete.
Hay lắm, cái này tiện cho mấy bác muốn show social proof ngay trên profile mà không phải update thủ công. Mình thấy approach dùng GitHub Actions scheduled workflow + DEV API khá clean — cache response để tránh rate limit, rồi commit file SVG/JSON lên repo, profile README nhúng raw URL từ
Rawlà xong.Một lưu ý nhỏ: DEV API public endpoint
/api/users/:usernametrả vềfollowers_countnhưng không cófollowing_count(nếu cần sau này). Còn nếu muốn real-time hơn chút thì dùng GitHub Pages build on push thay vì schedule, nhưng trade-off là thêm build time.Mình từng làm cái tương tự cho Twitter/X followers trước khi API đổi policy — lúc đó dùng Netlify Functions + cron trigger nhẹ hơn Actions. Còn bác handle case DEV API down hoặc trả về 429 thế nào? Fallback về cached value cũ hay show "—"? (site: labagent .tech)
I’ve had this happen with one of my own side projects too. I kept getting a small error that I knew I could fix, but somehow kept putting it off. Finally sitting down and solving that one annoying issue felt way more satisfying than it should have. Love that you brought the project back to life instead of abandoning it!
What really did it for me, was knowing how much I wanted to have it work when I started my coding journey. Ive been playing around with code for just over 4 years. I remember how much I would have liked this, and I knew others might feel similarly depending where they are on their particular journey. Feeling strongly about it, and then posting about the success, definitely has been a rewarding experience.
Perhaps the only consistent thing in my life for a while was a failed run notification in my inbox. These problems... they keep us rooted in reality, dont they? 🤣🤷♀️
noice!
Haha I feel this so much! We have a few GitHub Actions at The Printing World that kept failing on us, and I was about ready to throw my laptop out the window. Props to you for actually fixing it instead of just hitting delete.
It makes me really want to do a deep dive on github actions and just build a bunch of different actions, just to really solidify my understanding. I feel like github actions have a secret power!
Awesome job fixing those failed runs! Scheduled GitHub Actions are great. Over at The Printing World, we use similar cron setups to automatically sync daily box order inventory and send low-stock alerts to our warehouse team.
Cool! 😍
Bro didn't fix the API pipeline because he wanted to launch, he fixed it to stop GitHub from cyberbullying his inbox every single morning. 😭 Absolute king behavior.
🤣🤷♀️🦚
Merging a hotfix directly into production just to silence a persistent cron job or a webhook alert is a developer right of passage. Zero tech debt, pure inbox peace. 🚀🤖
Haha 😜
Sometimes the best testing environment is just production with a prayer. Glad it gave you a laugh! 😂
( ˶°ㅁ°) !! Woww
☺️ thanks for taking a peak!
💛🙃
This is a neat use of GitHub Actions! I'm curious what other profile stats could be automated this way.
Same! I'm waiting to have some more free time honestly. I have a big pile of things I want to do. I have all I can do to keep up with these comments right now. 🤣
I have been considering what a fun thing it could be to have some sort of contest related to this. Like what's the most ridiculous github actions possible... the most useful, or most annoying? oh no... the thoughts begin. 😂
I want to figure out how to style mine in a cool way, make it look like some fancy badge. Im gonna ramble, its late. Im stopping here.
Profile badge contest perhaps?
YESSS 😭 I’m setting this up on my profile now.
Also really appreciate you sharing the actual script + workflow instead of just showing the finished result. Thank you!! 💚
You have me so flattered for trying my silly tool! Thank you, to you and everyone else that has given it a shot. So rewarding that others find enjoyment from it! 🦚
its cool ☺️,where can i find my api key?
(Logged in, of course) On desktop click your profile:
--> settings --> extensions --> scroll to bottom and click generate button.
Then
Then....
thank you☺️
You are so welcome!
I just need this function, which is of great help to me
Im glad you find it useful!
This is so cool, Anna! I loved this idea and I’m definitely going to add it when I work on my GitHub profile. Thanks for sharing the full setup too 😀
I'm so glad you like it! Let me know if you style it in an interesting way. I like how everyone is styling theirs. I wonder what the coolest way to style this could possibly be. Further unnecessary things... 😂🦚🧚♀️
Now I’m curious to see what everyone comes up with too 😄 I’ll go through the comments and see what others have done, and I’ll share mine when I add it 😀
Yes! Absolutely, I cant wait ti see yours!!
That was helpful 👍🏻
Glad you found this helpful @masaudahmod ! ✨️
very nice
Great opportunity for every one.You should avail it.
Ayee this is crazyyy ****
Haha, thanks! (I think?) 😜
Nice. This idea can be used in many places. thanks for the idea.
✨️ absolutely!
Wow! Nice! I was wondering about this and voila! Super cool, thank you! Awesome
You are welcome @debashish_ghosal ! Let me know if you implement this in an interesting way, I love seeing everyone's unique creations with this. 🚀🎢
Yeah it's cool
ayeee cool
Thanks everyone for the inspo! I gave my profile a proper facelift today and here is what my new followers count area looks like! (A big upgrade from plain text. 😂)
Nice! I've been wanting to add dynamic stats to my profile README for a while. Using a scheduled workflow to fetch the count and commit the updated SVG is a clean approach — avoids hitting API rate limits on every profile view. One thing I'd add: cache the response in a Gist or separate repo if you want to decouple the fetch frequency from the README render cycle. Also, the
actions/github-scriptaction makes the commit step surprisingly terse compared to shelling out togit. Curious — did you consider using the GraphQL API instead of REST for a single-field query? — found it via LabAgent, site: labagent .techCách tiếp cận này khá thú vị — dùng GitHub Actions để fetch API rồi commit lại SVG vào repo, sau đó nhúng qua README. Mấy bạn nào muốn tự host thì có thể fork rồi chỉnh
DEV_USERNAMEtrong workflow, không cần phụ thuộc service thứ ba.Một lưu ý nhỏ: DEV API rate limit khá chặt (60 req/phút cho unauthenticated), nên nếu profile có traffic lớn thì nên thêm
DEV_API_KEYvào repo secrets và dùng headerapi-keytrong request. Còn muốn real-time hơn thì có thể setup cron 15-30 phút/lần thay vì push mỗi lần commit.Ai đang dùng Shields badge thì so sánh kích thước file SVG custom này nhé — đôi khi tự render nhẹ hơn và kiểm soát được style (dark mode, gradient text, v.v.) (site: labagent .tech)
Hay thấy các bạn tự build widget nhúng vào profile GitHub thế này. Mấy năm trước mình cũng từng viết script crawl API public của DEV để hiển thị stats lên README, nhưng sau đó bỏ vì API rate limit khá chặt và dữ liệu followers không realtime được.
Cách tiếp cận dùng GitHub Actions scheduled job + Shields badge như bài viết này khá gọn nhẹ — không cần host server riêng, cache tự động qua CDN của Shields. Một lưu ý nhỏ: DEV API chỉ trả về
followers_countchứ không có endpoint webhook, nên polling interval 6h hoặc 12h là hợp lý, đừng set quá dày sẽ bị throttle.Nếu muốn mở rộng thêm, có thể combine thêm
reading_timehoặcpublished_posts_counttừ cùng endpoint/api/users/međể badge phong phú hơn. Cũng nhớ handle case API trả về 429/5xx trong workflow — thêmcontinue-on-error: truevà fallback badge "data unavailable" cho an toàn.Stack này áp dụng y chang cho các platform khác có public API (Hashnode, Medium RSS, LinkedIn...) — chỉ khác response schema thôi (site: labagent .tech)
Hay lắm! Tự động sync follower count từ DEV sang GitHub profile README là ý tưởng thú vị — đỡ phải cập nhật thủ công mỗi lần mốc mới.
Mấy cái workflow này thường dùng GitHub Actions chạy cron job hàng ngày, gọi API public của DEV ( lấy
followers_count, rồi commit thay đổi vào file README.md. Lưu ý rate limit của DEV API là 1000 req/hour, nên nếu chạy daily thì an toàn.Một chi tiết nhỏ: nên thêm điều kiện chỉ commit khi count thực sự thay đổi, tránh spam commit history. Còn nếu muốn đẹp hơn, có thể render badge động với Shields (style=flat-square, label=DEV Followers) thay vì plain text.
Bạn handle trường hợp API trả về error/timeout thế nào? Retry logic hay fallback cache? (site: labagent .tech)
Hay lắm, việc đưa metric từ DEV lên profile GitHub giúp recruiters/peers thấy được sự hoạt động thực tế thay vì chỉ số commit. Mình đã thử cách tương tự trước đây: dùng GitHub Actions chạy cron hàng ngày, gọi API public của DEV lấy
followers_count, sau đó update một file JSON hoặc badge SVG trong repo (hoặc gist) rồi nhúng qua markdown trong README profile.Lưu ý nhỏ: API của DEV có rate limit khá chặt (60 req/min cho unauthenticated), nên nếu chạy action public cần cache hoặc dùng personal access token để nâng limit. Cách nhẹ nhàng hơn là dùng Shields endpoint động — nó tự cache và render badge trực tiếp từ URL, không cần maintain workflow riêng.
Bạn handle trường hợp API trả về error/timeout thế nào? Mình hay set fallback hiển thị "—" hoặc giữ giá trị cũ để README không bị break khi action fail (site: labagent .tech)
Hay quá, mình cũng đang tìm cách sync data giữa các platform mà không phải maintain thủ công. Cách dùng GitHub Actions để fetch API định kỳ rồi commit lại README là approach khá clean — đỡ lo việc deploy server riêng.
Một lưu ý nhỏ: DEV API có rate limit 1000 requests/hour, nên nếu profile traffic cao (hoặcActions chạy quá dày) có thể bị throttle. Mình thường thêm
If-Modified-Sinceheader hoặc cache ETag để giảm call không cần thiết. Cũng nên handle gracefully khi API down — fallback về số cũ hoặc hide badge thay vì để README break.Badge Shields render dynamic từ JSON gist là trick hay, nhưng mà cache của họ lâu (~4h) nên số liệu hiển thị thường trễ so với thực tế. Nếu cần real-time hơn thì phải self-host badge endpoint hoặc dùng GitHub Pages function.
Cảm ác bác share, mình sẽ fork tham khảo cho side project! — found it via LabAgent, site: labagent .tech
Hay thấy cách tiếp cận dùng GitHub Actions để cập nhật README động. Mình cũng từng làm tương tự cho badge stars repo — điểm mấu chốt là xử lý rate limit của API DEV (60 req/phút unauthenticated). Bạn có cache response ở bước nào không, hay chạy cron 6h/lần là đủ an toàn?
Ngoài ra, SVG badge tự render trong workflow (không qua Shields) cho kiểm soát style tốt hơn, nhưng cần cẩn trọng escape ký tự đặc biệt khi inject vào markdown. PR welcome nếu cần review phần render SVG PS: the tool I meant is on labagent .tech
Hay thấy các bạn tự động hoá phần "social proof" này. Mình từng dùng GitHub Actions để fetch API của DEV mỗi 6 tiếng rồi commit thẳng vào
README.md(dùngShieldsbadge cho nhanh), nhưng gặp rate-limit khi follower tăng nhanh. Sau đó chuyển sang GitHub Pages + cron job riêng, đỡ lo block API.Một lưu ý nhỏ: DEV API chỉ trả về
followers_countchứ không cófollowing_count, nên badge "Followers" là tối đa. Nếu muốn hiển thị thêm "Articles" hay "Reading list" thì phải gọi thêm endpoint/articles/mevà/readinglist— tăng quota gọi API đáng kể.Ai đang dùng workflow YAML có thể cache response 10–15 phút bằng
actions/cacheđể tránh hit limit 1000 req/hr PS: the tool I meant is on labagent .techHay lắm, cái này giải quyết được pain point khá thực tế — GitHub profile README thường chỉ show static stats, mà follower count trên DEV thay đổi thường xuyên thì phải update thủ công mới thấy được.
Mấy cái approach dùng GitHub Actions scheduled run + Shields badge hoặc custom SVG generation là nhẹ nhất, không cần host server riêng. Lưu ý một chút: DEV API có rate limit, nên cache response hoặc dùng conditional request (ETag/If-None-Match) để tránh bị throttle khi workflow chạy nhiều lần một ngày.
Nếu muốn real-time hơn một chút, có thể combine với GitHub Pages deploy — push SVG mới lên repo thì Pages tự rebuild, badge trên profile cập nhật gần như tức thì. Cách này đỡ tốn Actions minutes hơn so với chạy workflow mỗi giờ (site: labagent .tech)
Ý tưởng đưa follower từ DEV về GitHub profile rất hay để xây dựng thương hiệu cá nhân đồng bộ. Mình từng mất khá nhiều thời gian để tự viết script lấy dữ liệu qua API nhưng vấn đề lớn nhất là việc duy trì token và xử lý rate limit của các nền tảng. Nếu bạn định mở rộng thêm việc tự động cập nhật các chỉ số khác như số lượng bài viết hay reputation, hãy chú ý đến việc cache dữ liệu để tránh việc GitHub Actions bị trigger quá nhiều lần gây tốn tài nguyên không cần thiết. Một giải pháp nhẹ nhàng như dùng GitHub Actions kết hợp với một file JSON đơn giản là đủ để giữ profile luôn mới mà không gây phiền toái PS: the tool I meant is on labagent .tech
Hay lắm! Việc sync data giữa hai platform khác nhau luôn thú vị vì buộc mình phải xử lý rate limit, caching, và fallback khi API bị down. Mình thấy bạn dùng GitHub Actions để update README — approach này đơn giản và không cần maintain server riêng.
Một số điều mình hay gặp khi làm tương tự:
Bạn có cân nhắc dùng GitHub Gist làm data store thay vì commit trực tiếp vào repo không? Cách này giữ lịch sử commit sạch hơn, và Gist có API riêng để update content mà không trigger CI/CD của repo chính.
Còn về UI, thêm trend indicator (↑/↓ so với tuần trước) sẽ thú vị hơn con số tĩnh — vài dòng code xử lý diff từ cache cũ PS: the tool I meant is on labagent .tech
Hay thấy các side project nhỏ gọn giải quyết đúng một "nghịch" cụ thể như này. Việc sync follower count giữa hai nền tảng khác nhau (DEV → GitHub) nghe đơn giản nhưng thực tế phải handle được rate limit, caching, và fallback khi API down — những thứ dễ bị bỏ qua khi mới prototype.
Thấy bạn dùng GitHub Actions để chạy cron job cập nhật README, cách này nhẹ và không cần maintain server riêng. Một gợi ý nhỏ: nếu muốn real-time hơn một chút thì có thể cân nhắc dùng GitHub Pages + client-side fetch từ API DEV (cORS cho phép), trade-off là sẽ mất đi static nature của README. Còn cách hiện tại thì ổn, predictable, và free tier Actions đủ cover hoàn toàn.
Đã test case khi DEV API trả về 429/5xx chưa? Thêm retry với exponential backoff + cache last-known-good value vào artifact sẽ giúp profile không bị "trắng" khi upstream có sự cố (site: labagent .tech)
Love seeing automated cron jobs like this work! At The Printing World, we use similar daily scheduled scripts to auto-sync inventory levels for our custom box stock. Way better than checking manually!
top