Everything You'd Want to Ask Before Going Live.

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.

A self-hosted WordPress site running WordPress 6.4 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 — it's sold direct, not 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.

• Events & the OnCue block — create a liveblog and embed it in any post or page.
• Live console — a real-time composer in the WordPress admin with media, embeds, and polls.
• Real-time reader — updates stream from your own server; no third-party socket service.
• Inline polls — multiple-choice questions (2–4 options, optionally timed) dropped into any update, with live tallies.
• Roles and permissions — who can post, who can manage, enforced server-side.
• SEO and structured data — per-entry permalinks and LiveBlogPosting markup built in.

• Post from Slack — a dedicated channel becomes the liveblog feed.
• Post from Telegram — a bot in your group turns messages into updates.
• SMS and Messenger ingestion — texts to your Twilio number, or messages to your Facebook Page, become posts.
• Share out — published updates post themselves into Slack, Signal, Microsoft Teams, and Google Chat.
• AI Key Highlights — a grounded, cited TL;DR generated with your own Claude, OpenAI, or Gemini key, or a model you host yourself.
• Bluesky — thread the updates you mark onto your Bluesky account, and search public posts to embed.
• YouTube curation — search public videos and Shorts and embed picks straight from the composer.
• Reader share cards — a per-entry share row with rich Open Graph card images set in your site's typeface.
• More Coverage — a linked-headline list of your publication's own related articles.
• Moderation gate — approval-before-publish, per event or per source.

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.

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. The moderation module holds incoming updates for review before they publish, and you can scope it per event or per source — for example, auto-publish the newsroom Slack channel but hold everything arriving over SMS.

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:

• Your terms and your rates. Usage bills to your own accounts at each platform's own prices — no markup, no middleman quota.
• No shared infrastructure. Your webhooks point at your site; your AI calls go straight from your server to your provider.
• A minimal surface. A connection you haven't configured registers no endpoints at all.

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; or
• your existing WordPress security keys (AUTH_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.

1. In WordPress, open OnCue → Connections and find the Slack card.
2. Get a one-time setup code from Slack: open Slack's app configuration tokens page, scroll to “Your App Configuration Tokens”, click Generate Token, and copy the Access Token.
3. Paste that code into OnCue. It's used once — to create the OnCue app in your workspace with the right settings — and never saved.
4. Click Add to Slack to install the app to your workspace. Done — every event on the site can now use Slack, with no per-event setup.

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 — including photos and edits.

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.

1. In Telegram, message @BotFather, send /newbot, and copy the bot token it gives you.
2. Still with @BotFather, send /setprivacy, pick your bot, and choose Disable — this lets the bot read all messages in a group, not just commands.
3. Send /setdomain, pick your bot, and enter your site's domain — this enables one-click account linking for your team.
4. In WordPress, open OnCue → Connections, paste the bot token, and Save.
5. Click “Connect bot to this site” — that tells Telegram where to deliver the bot's messages.

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.

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.

1. In the Twilio Console, copy your Account SID and Auth Token into OnCue's Connections screen.
2. Open your Twilio number's settings and, under “A message comes in”, set the webhook to the URL OnCue shows you (HTTP POST).
3. On the event, set which Twilio number it listens on — one event per number.

Messages sent to your Facebook Page — text and photos — become posts.

1. Create (or open) a Meta app with the Messenger product; copy its App Secret and a Page Access Token into OnCue.
2. Choose any Verify Token and enter the same value in OnCue and in Meta's webhook screen.
3. Point Meta's webhook Callback URL at the address OnCue shows you and subscribe to the messages field.

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:

• Share to: tick “Send to Bluesky” on an update in the live console and it threads onto your publication's Bluesky account — you choose exactly which posts go, and they chain into one growing thread per event.
• Search & embed: search public Bluesky posts about your event from the composer and embed the ones you pick.

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.

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.

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.

• Attack surface = enabled features. A disabled module registers no REST routes and schedules no jobs.
• Signed webhooks. Inbound messages from Slack, Telegram, Twilio, and Messenger are verified against each platform's signing scheme before anything is processed.
• Secrets encrypted at rest with the key kept outside the database (see BYOK).
• Server-side authorization. Who can post, moderate and manage is enforced in the server, not the UI.
• Everything sanitized. Content is sanitized on the way in, whichever channel it arrives from, and AI output is treated as untrusted input too.

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.