What OnCue includes, how bring-your-own-keys works, and step-by-step setup for every connection. Five minutes here and you're ready for your first event.
OnCue is a liveblogging plugin for WordPress. You create an event, drop the OnCue block into any post, and updates stream to that page in real time — served by your own site, styled by your own theme.
What makes it different is where updates come from: your team can post straight from Slack, Telegram, SMS, or Facebook Messenger, so nobody needs a CMS login in the field. Published updates can also flow back out — into Slack, Signal, Teams, or Google Chat — and thread onto Bluesky and Threads.
A self-hosted WordPress site running WordPress 6.5 or newer on PHP 8.0 or newer. That's it — the core liveblog works the moment you activate the plugin, with no external services.
Chat connections and AI highlights are optional add-ons, and each one uses your account with that platform (see BYOK below).
Not on WordPress? OnCue can run as a stand-alone live engine next to Ghost, a static site, or any other stack — see Beyond WordPress. The full stream, or any single update, embeds on your main site with a copy-paste snippet.
No. OnCue is a plugin you install on your own site from the WordPress plugin directory — it isn't run as SaaS. Your entries, your reader traffic, and your credentials all stay on your server. There is no OnCue cloud in the middle.
Contributors post from the chat apps they already use — a message in the connected Slack channel or Telegram group simply becomes a liveblog update, with their name on it. Editors who prefer the site get a live console inside WordPress with a full composer: text, photos, video, embeds, and polls.
A fast live page on your domain, inheriting your theme's fonts and styling. New updates appear without refreshing, an optional AI "Key highlights" box keeps latecomers current, and each entry has its own permalink and structured data so search engines (and answer engines) can cite it.
OnCue is a lean core plus opt-in modules. Anything you haven't switched on registers no routes, schedules no jobs, and adds no attack surface.
An author drops a multiple-choice question (two to four options) into any update, mixed with text and media. Readers vote once per browser and watch the tallies move live. Polls can run open-ended or close automatically after a duration you set.
If you switch on reader reactions, yes — a thumbs-up on individual updates, no sign-in required, with counts that refresh live for everyone. It's deliberately the lightest possible signal: there's no comment thread to moderate, and the counts show up in Stats so you can see which moments actually landed.
Each event has an Appearance tab: accent, card background, border, and muted-text colors, plus a contained (640px) or full-width layout. OnCue checks contrast as you pick and warns you before you ship something unreadable, and the colors are scoped to that one event so a partner-branded liveblog can't leak its palette onto your other coverage.
Typeface is deliberately not customizable — the reader always inherits your theme's fonts, so coverage looks like the rest of your site rather than an embedded widget.
Every entry can carry a share row linking to its own URL, which serves a rich Open Graph card — a generated image of the update, rendered in your site's own typeface. When someone shares a moment from your coverage, the preview looks like your site, not a generic link.
During a live event the story is also happening on the open web. With a Bluesky connection or a YouTube API key, editors can search public Bluesky posts and public YouTube videos/Shorts about the event from inside the composer and embed the best ones directly into the stream — no tab-switching, no copy-pasting URLs.
Yes. Turn on the moderation module for an event, and posts from anyone other than an Editor, an Administrator, or the event's creator wait for approval, whichever channel they came from. Approved posts land in the timeline at the time they were written, so the story stays in order.
OnCue ships the pipes for each platform, but never ships credentials. Every connection runs on your own account — that's the whole model.
Every integration — Slack, Telegram, Twilio, Messenger, Bluesky, YouTube, Claude, or OpenAI — runs on credentials you create with that platform and paste into OnCue's Connections screen. Nothing turns on until you supply your own keys.
That buys you three things:
Encrypted at rest with libsodium, on by default. The encryption key never lives in the database, so a database dump alone cannot decrypt your credentials. The key comes from one of two places:
ONCUE_ENCRYPTION_KEY in wp-config.php (a 32+ character random string) — preferred, because you can rotate it independently of WordPress; orAUTH_KEY etc.), which every properly installed site already has — so encryption works with zero extra setup.Heads up: if you rotate your WordPress salts without setting a dedicated key, previously stored credentials become undecryptable — just re-enter them under Connections.
Whatever the platforms charge you — OnCue adds nothing on top. Telegram bots and Slack apps are free. Bluesky is free. Twilio bills per SMS at your rates. YouTube search runs on Google's free API quota (roughly 100 searches a day, and OnCue caches repeat queries to stretch it). AI highlights bill to whichever provider key you connect — Claude, OpenAI, or Gemini — and OnCue summarizes incrementally to keep those calls small; on a self-hosted model they cost nothing at all.
Slack is the recommended anchor: your team posts from it, the liveblog posts back to it, and onboarding is the smoothest of any connection. You never hand-build a Slack app — OnCue creates it for you. Full step-by-step in the admin guide →
On each event's setup screen you pick the channel that feeds it — one channel per event, so a stray message in #general never hits your liveblog. For public channels, OnCue's bot joins automatically when you pick one. For private channels, invite the bot (/invite @OnCue) and it appears in the picker.
From then on, every message posted in that channel becomes a liveblog update, photos included. To fix an update after it posts, edit it in the live console; changes made to the Slack message don't carry over.
Each contributor links their Slack identity to their WordPress account once — a per-person sign-in from their WordPress profile. After that, their channel messages publish under their own name. Unlinked senders can be held for moderation or attributed to a house account, depending on your settings.
Yes — sharing back is set per event. Published updates (from the console, SMS, Telegram, anywhere) post into the Slack channel with the author's name inline, so the channel doubles as the team's live feed. OnCue never echoes a message back to the channel it came from, so there are no duplicate posts.
The lightest connection of all — a free bot and about three minutes with @BotFather.
/newbot, and copy the bot token it gives you./setprivacy, pick your bot, and choose Disable — this lets the bot read all messages in a group, not just commands./setdomain, pick your bot, and enter your site's domain — this enables one-click account linking for your team.Add your bot to the Telegram group (or use a direct chat with it), then bind that chat to an event on the event's setup screen. Every message in the chat — text and photos — becomes a liveblog update. Telegram is a posting channel only: to give remote contributors a live feed of everything published, share the event into a Slack channel, Signal group, or Teams/Google Chat space.
Because you set /setdomain, each team member can link their Telegram account with one click from their WordPress profile (Users → Profile). Once linked, their group messages publish under their own WordPress byline.
Every connection is honest about what it does today: which ones your team posts from, which ones the liveblog shares to, and what's still on the roadmap.
Reporters text updates to your Twilio number and each text becomes a post — ideal for the field, since it needs no app and no data connection beyond SMS.
Messages sent to your Facebook Page — text and photos — become posts.
Share the liveblog into a Signal group through your own self-hosted signal-cli REST bridge — Signal has no hosted API, so you run the bridge and OnCue talks to it. Enter the bridge's base URL and its registered number, then pick the group ID to share into. Posting from Signal is on the roadmap.
Both work the same way and take about a minute: create an Incoming Webhook in the Teams channel or Google Chat space you want the liveblog shared to, copy its URL, and paste it into OnCue. Posting from Teams or Chat into OnCue requires their bot frameworks and is on the roadmap.
Two directions, one connection:
Setup: in Bluesky, create an app password (Settings → Privacy and security → App Passwords) and enter it with your handle. Never use your account password. Leave the service URL blank unless you self-host your own PDS.
Mark an update in the live console — or react 🧵 to its message in Slack — and it threads onto your publication's Threads account, one growing thread per event. Same selective model as Bluesky: you choose what goes, everything else stays off the account.
Setup: create a Meta app with the Threads API use case, add your Threads account as an app user with the threads_basic and threads_content_publish permissions, generate a long-lived access token, and paste it into OnCue. Because you only ever post to your own account, this needs no Meta app review, and OnCue refreshes the token before it expires.
Search public YouTube videos and Shorts about your event and embed picks straight from the composer. In the Google Cloud Console: create a project, enable the YouTube Data API v3, create an API key under Credentials, and paste it into OnCue. Restrict the key to that API for safety. Google caps search quota at roughly 100 searches a day; OnCue caches repeat searches to protect it.
A running TL;DR at the top of your coverage — grounded, cited, and powered by your own key.
As your event unfolds, OnCue keeps a short summary current at the top of the page so a reader arriving late catches up in seconds. It refreshes automatically as updates land (debounced, so it isn't calling a model on every post) and each highlight cites the entries it came from.
It's built specifically not to. The model is grounded only in your event's own published updates — it summarizes what your team posted, nothing else. Links in the summary are verified against your actual entries, so it can't invent URLs. And editors keep control: you can edit the summary or pin your own version, and the reader endpoint only ever serves stored text — it never triggers a model call.
Four options, all on your own key: Anthropic (Claude) — the default — OpenAI, Google Gemini, or a self-hosted / OpenAI-compatible server (Ollama, vLLM, Together, Groq, and friends), which means highlights can run on open-weight models on your own hardware. Pick the provider and model under Connections and paste that provider's API key. The key is a spend credential, so it's stored encrypted like every other secret and used only to generate summaries. To keep costs low, OnCue summarizes incrementally — each refresh builds on the last instead of re-reading the whole event.
Per-event reader numbers that need no third-party account — and no cookies. Full setup in the admin guide →
No. Every event has a Stats screen that works the moment you activate the plugin, measured on your own server and stored in your own database: readers and unique readers, average engaged time, updates seen per reader, interactions, traffic sources, devices, countries, and a live “reading right now” count while coverage is running.
If you'd rather read the numbers from your own GA4 property, you can point Stats at it instead — that path needs a Google Cloud service account with Viewer access and your GA4 property ID.
Neither. Collection is cookieless, and OnCue stores no personal data. Unique readers use a fingerprint that rotates daily, so day-by-day trends are exact while lifetime totals are a modest over-count — an honest trade we'd rather make than track people. IP addresses are used only to derive an approximate country and are never saved.
Yes, and it's independent of which source Stats reads from. OnCue can mirror reader interactions — views, time following, poll votes, reactions, and shares — into the GA4 or Google Tag Manager tag your site already carries, labeled with the event so coverage traffic is separable. Not on Google? The same events fire as DOM events any tool can listen for. It's off by default and OnCue sets no cookies of its own, so your existing consent setup keeps working unchanged.
By design: entries are public content served to readers — encrypting them would break the live stream without protecting anything secret. The same goes for non-secret identifiers like a public Slack client ID. Encrypting the whole database or disk is your host's job (encrypted volumes, MySQL TDE); OnCue encrypts the things only it holds — your credentials.
Only what you've wired up, and only to your own accounts: shared updates go to the chat platforms you connected, marked posts go to Bluesky, and — if AI highlights are on — your event's published entries go to your chosen AI provider under your key. Nothing routes through OnCue's infrastructure, because there isn't any.
Install OnCue, drop the block into a post, and you're live. Connect the rest when you need it.