Knowledge Hub
As organizations scale their Temporal adoption, the need for centralized, consistent knowledge becomes critical. Mature Temporal organizations establish internal knowledge hubs to address common challenges that emerge when multiple teams adopt Temporal independently.
This guide covers what belongs in a knowledge hub, how to communicate it, and how to keep it useful over time. To bootstrap your knowledge hub, use the Temporal Platform Hub template as a starting point.
The problem
Without a centralized knowledge base, organizations often experience:
- Fragmented expertise: Tribal knowledge stays siloed within teams, leading to inconsistent Temporal implementations and repeated mistakes across the organization.
- Slow onboarding: New developers spend weeks piecing together information from scattered sources, Slack threads, and ad-hoc meetings.
- Inconsistent patterns: Teams develop their own conventions for Workflow design, error handling, and testing, making cross-team collaboration and code reuse difficult.
- Redundant support burden: Platform teams answer the same questions repeatedly, diverting resources from strategic work.
- Compliance and security gaps: Without standardized guidance, teams may inadvertently introduce security vulnerabilities or miss compliance requirements.
Value of a Temporal Knowledge Hub
Organizations that invest in an internal Temporal knowledge hub see measurable improvements:
| Benefit | Impact |
|---|---|
| Accelerated onboarding | Reduce onboarding from weeks to days with clear learning paths and starter templates. |
| Consistent standards | Establish conventions for Namespaces, Workers, and error handling across all teams. |
| Reduced support toil | Up to 90% fewer repetitive questions with self-service documentation. |
| Faster time-to-production | Ship features faster with validated patterns and decision frameworks. |
| Improved compliance | Ensure consistent security controls and access management across teams. |
Quantifying the value
These benefits become concrete when you attach metrics to them. The following table shows example indicators that organizations use to measure the impact of their knowledge hub, along with realistic before-and-after targets:
| Metric | Before Knowledge Hub | Target | What it tells you |
|---|---|---|---|
| Time to first Workflow | Days to weeks (developers piece together scattered resources) | Under 30 minutes (developers follow a single getting started guide) | Measures onboarding friction. A short time to first Workflow signals that your getting started guide is effective. |
| Time to Workflow in production | Weeks to months (blocked by unclear Namespace provisioning and deployment processes) | Under 2 weeks (developers follow documented self-service provisioning) | Measures the gap between development and delivering value. Long times point to missing documentation and automation opportunities. |
| Support question rate | 20-30+ questions per week to the Platform team via Slack | Fewer than 5 per week | Measures self-service resolution. A declining trend shows that developers are finding answers in the knowledge hub instead of asking the Platform team. |
| Knowledge Hub traffic | N/A (no centralized resource exists) | Steady or growing page views per month | Identifies which content developers rely on and where gaps remain. Declining traffic on a page may indicate it is outdated; high traffic with high bounce rates may indicate the page is not answering the question. |
These metrics create a feedback loop: measure, identify gaps, improve content, and measure again. The How to maintain and communicate your Knowledge Hub section covers how to operationalize this feedback loop.
What belongs in your Knowledge Hub
The following outline shows what to include, organized by where developers are in their journey.
Evaluate - increases Knowledge Hub traffic, decreases support question rate
Help developers understand what Temporal is and whether it fits their problem before they write code.
- Temporal overview explains what Temporal is, why your organization chose it, and the business value metrics that justify adoption.
- Decision framework provides qualifying questions, good and bad use cases, and alternative recommendations so developers can determine whether Temporal fits their problem.
Build - decreases time to first Workflow
Give developers a single path from zero to a running Workflow.
- Getting started walks developers through a 30-minute quickstart covering environment setup, a starter template, and running a first Workflow locally and on Temporal Cloud.
- Learning paths structures self-paced courses from foundational to advanced topics, tailored by persona, and links to Temporal's free training.
Ship - decreases time to Workflow in production
Provide the architecture standards and guardrails developers need to go from a local prototype to a production deployment.
- Architecture and standards documents Namespace conventions, connectivity requirements, and Worker deployment standards that every team follows.
- Cost guidance explains billable Actions, storage tiers, and cost-saving tips so developers build cost-efficient Workflows.
- Shared responsibility defines an ownership matrix between Platform and Application teams across IAM, infrastructure, development, deployment, observability, and operations.
- Design patterns curates Workflow patterns with descriptions and code sample links that developers can adopt directly.
Operate - decreases support question rate
Give developers the tools to self-serve during incidents and find answers without escalating to the Platform team.
- Troubleshooting and escalation covers observability tools, runbooks for common issues, escalation paths, SLAs, and example alert definitions.
- Support and FAQs documents your support tier, ticket submission process, Temporal account contacts, expert-led session types, and frequently asked questions.
What doesn't belong in your Knowledge Hub
A knowledge hub is not a mirror of Temporal's official documentation. Avoid duplicating SDK API references, concept explanations, or release notes that Temporal already maintains. When that content changes, your copy becomes a source of confusion rather than clarity. Instead, link to the official docs and reserve your knowledge hub for organization-specific decisions, conventions, and operational procedures that Temporal's public documentation does not cover.
How to maintain and communicate your Knowledge Hub
Assign ownership
Designate a Platform team or developer experience team as the owner. This team is responsible for initial content creation, ongoing maintenance, and reviewing contributions from application teams.
Make it discoverable
A knowledge hub that developers can not find is the same as not having one.
- Register a short URL (for example,
go/temporal) that redirects to the knowledge hub. - Pin the link in your Temporal-related communication channels (e.g. Slack, Microsoft Teams).
- When answering questions in Slack, respond with a link to the relevant knowledge hub page instead of re-explaining inline. This builds the habit of checking the hub first.
Review metrics regularly
Track the metrics from Quantifying the value on a regular cadence to identify what is working and where gaps remain.
Capture every question that reaches the Platform team through Slack or tickets as a candidate for new content.
Solicit contributions from application teams through a lightweight process such as a pull request template.
Keep content current
- Review on a cadence: Review each page at least quarterly. Assign a review owner and date to each page so staleness is visible.
- Tie updates to events: Update the knowledge hub whenever your organization changes its Temporal architecture, updates its deployment tooling, or modifies its shared responsibility model.
- Prune aggressively: Remove or archive content that no longer applies. Outdated documentation is worse than no documentation because developers follow it and get unexpected results.
Get started
Start with the Temporal Platform Hub template as your foundation.